Its not an actual answer but rather an idea based upon Dan's mail. What if pam_keyring would be patched to supply the correct label? Just food for thought On 02/01/2015 02:00 PM, selinux-request@lists.fedoraproject.org wrote:
Send selinux mailing list submissions to selinux@lists.fedoraproject.org
To subscribe or unsubscribe via the World Wide Web, visit https://admin.fedoraproject.org/mailman/listinfo/selinux or, via email, send a message with subject or body 'help' to selinux-request@lists.fedoraproject.org
You can reach the person managing the list at selinux-owner@lists.fedoraproject.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of selinux digest..."
Today's Topics:
- Re: Issues with sshd writing to the kernel keyring (Jason L Tibbitts III)
Message: 1 Date: Sat, 31 Jan 2015 15:45:31 -0600 From: Jason L Tibbitts III tibbs@math.uh.edu To: Daniel J Walsh dwalsh@redhat.com Cc: selinux@lists.fedoraproject.org Subject: Re: Issues with sshd writing to the kernel keyring Message-ID: ufay4oi1v5w.fsf@epithumia.math.uh.edu Content-Type: text/plain
"DJW" == Daniel J Walsh dwalsh@redhat.com writes:
DJW> The labelling of the kernel keyring has never been handled DJW> correctly. The keyring gets created with a label based on the DJW> creating object then all sorts of other confined domains end up DJW> using the same keyring.
Ah, that makes a lot of sense. I have managed to get around it by restarting things, but knowing that whatever creates the keyring specifies the label does explain what I'm seeing, including the rare startup race.
Do you know if it's possible to somehow look at the kernel keyring and see the labeling of things? /proc/keys doesn't tell me.
DJW> I would just allow the access. You should open a bug with DJW> selinux-policy to allow sshd_t to write to the gssd_t keyring.
I reopened the existing bug, which was on F20 (and seemingly solved there) but which didn't get carried over to F21 somehow. That is https://bugzilla.redhat.com/show_bug.cgi?id=1063827
I can open a new ticket if that would be better.
- J<
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
End of selinux Digest, Vol 132, Issue 1
On 02/01/2015 06:50 AM, George Karakougioumtzis wrote:
Its not an actual answer but rather an idea based upon Dan's mail. What if pam_keyring would be patched to supply the correct label? Just food for thought
pam_keyring supplies the keyring of the logged in user, but in several cases we have other entities creating keyrings, like sssd, or services like gssd. If the keyring is a UID based keyring, it does not necessarily follow SELinux rules. Can I have multiple uid=0 keyrings which are separated? We are havin major problems with containers and the keyring. Where we basically want a separate keyring for each container even if the containers are all running with the same UID.
On 02/01/2015 02:00 PM, selinux-request@lists.fedoraproject.org wrote:
Send selinux mailing list submissions to selinux@lists.fedoraproject.org
To subscribe or unsubscribe via the World Wide Web, visit https://admin.fedoraproject.org/mailman/listinfo/selinux or, via email, send a message with subject or body 'help' to selinux-request@lists.fedoraproject.org
You can reach the person managing the list at selinux-owner@lists.fedoraproject.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of selinux digest..."
Today's Topics:
- Re: Issues with sshd writing to the kernel keyring (Jason L Tibbitts III)
Message: 1 Date: Sat, 31 Jan 2015 15:45:31 -0600 From: Jason L Tibbitts III tibbs@math.uh.edu To: Daniel J Walsh dwalsh@redhat.com Cc: selinux@lists.fedoraproject.org Subject: Re: Issues with sshd writing to the kernel keyring Message-ID: ufay4oi1v5w.fsf@epithumia.math.uh.edu Content-Type: text/plain
> "DJW" == Daniel J Walsh dwalsh@redhat.com writes:
DJW> The labelling of the kernel keyring has never been handled DJW> correctly. The keyring gets created with a label based on the DJW> creating object then all sorts of other confined domains end up DJW> using the same keyring.
Ah, that makes a lot of sense. I have managed to get around it by restarting things, but knowing that whatever creates the keyring specifies the label does explain what I'm seeing, including the rare startup race.
Do you know if it's possible to somehow look at the kernel keyring and see the labeling of things? /proc/keys doesn't tell me.
DJW> I would just allow the access. You should open a bug with DJW> selinux-policy to allow sshd_t to write to the gssd_t keyring.
I reopened the existing bug, which was on F20 (and seemingly solved there) but which didn't get carried over to F21 somehow. That is https://bugzilla.redhat.com/show_bug.cgi?id=1063827
I can open a new ticket if that would be better.
- J<
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
End of selinux Digest, Vol 132, Issue 1
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
What if there would exist a central module responsible for handling the keyrings? It could expose a netlink socket or a dbus interface, or tcp socket(most likely since there is network authentication with ipa/kerberos) for various like login,sssd or kerberos to subscribe/communicate and get notified about events and then create the keyrings with a context? Well thats definitely not selinux'ish strictly speaking but a more general problem. On 02/02/2015 07:10 PM, Daniel J Walsh wrote:
On 02/01/2015 06:50 AM, George Karakougioumtzis wrote:
Its not an actual answer but rather an idea based upon Dan's mail. What if pam_keyring would be patched to supply the correct label? Just food for thought
pam_keyring supplies the keyring of the logged in user, but in several cases we have other entities creating keyrings, like sssd, or services like gssd. If the keyring is a UID based keyring, it does not necessarily follow SELinux rules. Can I have multiple uid=0 keyrings which are separated? We are havin major problems with containers and the keyring. Where we basically want a separate keyring for each container even if the containers are all running with the same UID.
On 02/01/2015 02:00 PM, selinux-request@lists.fedoraproject.org wrote:
Send selinux mailing list submissions to selinux@lists.fedoraproject.org
To subscribe or unsubscribe via the World Wide Web, visit https://admin.fedoraproject.org/mailman/listinfo/selinux or, via email, send a message with subject or body 'help' to selinux-request@lists.fedoraproject.org
You can reach the person managing the list at selinux-owner@lists.fedoraproject.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of selinux digest..."
Today's Topics:
- Re: Issues with sshd writing to the kernel keyring (Jason L Tibbitts III)
Message: 1 Date: Sat, 31 Jan 2015 15:45:31 -0600 From: Jason L Tibbitts III tibbs@math.uh.edu To: Daniel J Walsh dwalsh@redhat.com Cc: selinux@lists.fedoraproject.org Subject: Re: Issues with sshd writing to the kernel keyring Message-ID: ufay4oi1v5w.fsf@epithumia.math.uh.edu Content-Type: text/plain
>> "DJW" == Daniel J Walsh dwalsh@redhat.com writes:
DJW> The labelling of the kernel keyring has never been handled DJW> correctly. The keyring gets created with a label based on the DJW> creating object then all sorts of other confined domains end up DJW> using the same keyring.
Ah, that makes a lot of sense. I have managed to get around it by restarting things, but knowing that whatever creates the keyring specifies the label does explain what I'm seeing, including the rare startup race.
Do you know if it's possible to somehow look at the kernel keyring and see the labeling of things? /proc/keys doesn't tell me.
DJW> I would just allow the access. You should open a bug with DJW> selinux-policy to allow sshd_t to write to the gssd_t keyring.
I reopened the existing bug, which was on F20 (and seemingly solved there) but which didn't get carried over to F21 somehow. That is https://bugzilla.redhat.com/show_bug.cgi?id=1063827
I can open a new ticket if that would be better.
- J<
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
End of selinux Digest, Vol 132, Issue 1
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Well you would need a mechanism to have multiple keyrings associated with each different SELinux label. With potentially more depending on if there are multiple UIDs with a single SELinux label.
On 02/03/2015 08:37 AM, George Karakougioumtzis wrote:
What if there would exist a central module responsible for handling the keyrings? It could expose a netlink socket or a dbus interface, or tcp socket(most likely since there is network authentication with ipa/kerberos) for various like login,sssd or kerberos to subscribe/communicate and get notified about events and then create the keyrings with a context? Well thats definitely not selinux'ish strictly speaking but a more general problem. On 02/02/2015 07:10 PM, Daniel J Walsh wrote:
On 02/01/2015 06:50 AM, George Karakougioumtzis wrote:
Its not an actual answer but rather an idea based upon Dan's mail. What if pam_keyring would be patched to supply the correct label? Just food for thought
pam_keyring supplies the keyring of the logged in user, but in several cases we have other entities creating keyrings, like sssd, or services like gssd. If the keyring is a UID based keyring, it does not necessarily follow SELinux rules. Can I have multiple uid=0 keyrings which are separated? We are havin major problems with containers and the keyring. Where we basically want a separate keyring for each container even if the containers are all running with the same UID.
On 02/01/2015 02:00 PM, selinux-request@lists.fedoraproject.org wrote:
Send selinux mailing list submissions to selinux@lists.fedoraproject.org
To subscribe or unsubscribe via the World Wide Web, visit https://admin.fedoraproject.org/mailman/listinfo/selinux or, via email, send a message with subject or body 'help' to selinux-request@lists.fedoraproject.org
You can reach the person managing the list at selinux-owner@lists.fedoraproject.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of selinux digest..."
Today's Topics:
- Re: Issues with sshd writing to the kernel keyring (Jason L Tibbitts III)
Message: 1 Date: Sat, 31 Jan 2015 15:45:31 -0600 From: Jason L Tibbitts III tibbs@math.uh.edu To: Daniel J Walsh dwalsh@redhat.com Cc: selinux@lists.fedoraproject.org Subject: Re: Issues with sshd writing to the kernel keyring Message-ID: ufay4oi1v5w.fsf@epithumia.math.uh.edu Content-Type: text/plain
>>> "DJW" == Daniel J Walsh dwalsh@redhat.com writes:
DJW> The labelling of the kernel keyring has never been handled DJW> correctly. The keyring gets created with a label based on the DJW> creating object then all sorts of other confined domains end up DJW> using the same keyring.
Ah, that makes a lot of sense. I have managed to get around it by restarting things, but knowing that whatever creates the keyring specifies the label does explain what I'm seeing, including the rare startup race.
Do you know if it's possible to somehow look at the kernel keyring and see the labeling of things? /proc/keys doesn't tell me.
DJW> I would just allow the access. You should open a bug with DJW> selinux-policy to allow sshd_t to write to the gssd_t keyring.
I reopened the existing bug, which was on F20 (and seemingly solved there) but which didn't get carried over to F21 somehow. That is https://bugzilla.redhat.com/show_bug.cgi?id=1063827
I can open a new ticket if that would be better.
- J<
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
End of selinux Digest, Vol 132, Issue 1
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org