[sssd PR#616][opened] become_user: add supplementary groups so ad provider can access keytab
URL: https://github.com/SSSD/sssd/pull/616 Author: asheplyakov Title: #616: become_user: add supplementary groups so ad provider can access keytab Action: opened
PR body: """ For security reasons one might want to run providers as a non-privileged user (say, _sssd). However some providers (in particular ad) might need an access to restricted (non world-readable) files (for instance, /etc/krb5.keytab). One of the possible ways to solve the problem is to - add a special group (for instance, _keytab) - set the owner:group of the file in question to root:_keytab - set the permissions of the file in question to 640 - make the _sssd user a member of the _keytab group
For this to work become_user should assign supplementary groups, which is what this patch does. """
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/616/head:pr616 git checkout pr616
URL: https://github.com/SSSD/sssd/pull/616 Title: #616: become_user: add supplementary groups so ad provider can access keytab
centos-ci commented: """ Can one of the admins verify this patch? """
See the full comment at https://github.com/SSSD/sssd/pull/616#issuecomment-404174418
URL: https://github.com/SSSD/sssd/pull/616 Title: #616: become_user: add supplementary groups so ad provider can access keytab
centos-ci commented: """ Can one of the admins verify this patch? """
See the full comment at https://github.com/SSSD/sssd/pull/616#issuecomment-404174417
URL: https://github.com/SSSD/sssd/pull/616 Title: #616: become_user: add supplementary groups so ad provider can access keytab
fidencio commented: """ ok to test """
See the full comment at https://github.com/SSSD/sssd/pull/616#issuecomment-404221858
URL: https://github.com/SSSD/sssd/pull/616 Title: #616: become_user: add supplementary groups so ad provider can access keytab
sumit-bose commented: """ Thank you for the patch it looks quite interesting.
I wonder if you wouldn't be able to achieve the same by setting the primary group of the _sssd user to _keytab?
Additionally if you think that a secondary group is really necessary I think it would be better to add a config option for this so that you can add e.g. to the [domain/...] section 'secondary_gid = 12345'. This way /etc/group (where is _sssd user is added to the _keytab group) is not a required part of the SSSD configuration and the initgroups() call can be avoided because it might be expensive at some places where become_user() is called. """
See the full comment at https://github.com/SSSD/sssd/pull/616#issuecomment-404270980
URL: https://github.com/SSSD/sssd/pull/616 Title: #616: become_user: add supplementary groups so ad provider can access keytab
jhrozek commented: """ On Wed, Jul 11, 2018 at 11:42:44AM -0700, sumit-bose wrote:
Thank you for the patch it looks quite interesting.
I wonder if you wouldn't be able to achieve the same by setting the primary group of the _sssd user to _keytab?
This would be my preference too. Or owning the keytab by keytab.sssd. Alternatively, could the keytab file allow the sssd user to read the contents with a POSIX ACL? (setfacl -m u:sssd:r /etc/krb5.keytab)
Additionally if you think that a secondary group is really necessary I think it would be better to add a config option for this so that you can add e.g. to the [domain/...] section 'secondary_gid = 12345'. This way /etc/group (where is _sssd user is added to the _keytab group) is not a required part of the SSSD configuration
I don't understand this part, I'm sorry. Do you propose that sssd_be runs with some supplementary GIDs, but the responders don't? This makes sense, but in general I'm not sure I like constructing some artificial identity.
and the initgroups() call can be avoided because it might be expensive at some places where become_user() is called.
This is a fair comment, although storing the sssd user in a remote directory (which is realistically the only setup which might be slow) doesn't strike me as the best idea.
"""
See the full comment at https://github.com/SSSD/sssd/pull/616#issuecomment-404281393
URL: https://github.com/SSSD/sssd/pull/616 Title: #616: become_user: add supplementary groups so ad provider can access keytab
sumit-bose commented: """ On Wed, Jul 11, 2018 at 12:19:33PM -0700, Jakub Hrozek wrote:
On Wed, Jul 11, 2018 at 11:42:44AM -0700, sumit-bose wrote:
Thank you for the patch it looks quite interesting.
I wonder if you wouldn't be able to achieve the same by setting the primary group of the _sssd user to _keytab?
This would be my preference too. Or owning the keytab by keytab.sssd. Alternatively, could the keytab file allow the sssd user to read the contents with a POSIX ACL? (setfacl -m u:sssd:r /etc/krb5.keytab)
Additionally if you think that a secondary group is really necessary I think it would be better to add a config option for this so that you can add e.g. to the [domain/...] section 'secondary_gid = 12345'. This way /etc/group (where is _sssd user is added to the _keytab group) is not a required part of the SSSD configuration
I don't understand this part, I'm sorry. Do you propose that sssd_be runs with some supplementary GIDs, but the responders don't? This makes sense, but in general I'm not sure I like constructing some artificial identity.
It is not about identity but giving the sssd_be the needed privileges to access the file. But as said above my preferences would be to use the primary gid or as you suggested POSIX ACLs to solve the issue.
and the initgroups() call can be avoided because it might be expensive at some places where become_user() is called.
This is a fair comment, although storing the sssd user in a remote directory (which is realistically the only setup which might be slow) doesn't strike me as the best idea.
become_user() is also used in krb5_child to switch to the user trying to log in to create the ccache with the right permissions.
-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/SSSD/sssd/pull/616#issuecomment-404281393
"""
See the full comment at https://github.com/SSSD/sssd/pull/616#issuecomment-404285945
URL: https://github.com/SSSD/sssd/pull/616 Title: #616: become_user: add supplementary groups so ad provider can access keytab
asheplyakov commented: """
I wonder if you wouldn't be able to achieve the same by setting the primary group of the _sssd user to _keytab?
This way other daemons which need access to keytab (apache, postgresql, you name it) might be able to read sssd caches and logs (which belong to _sssd:_keytab). It looks like sssd is careful enough to chmod 600 all those files, yet it's better to avoid possible bugs.
could the keytab file allow the sssd user to read the contents with a POSIX ACL?
- often keytab is managed automatically by `samba-tool join` or similar tools. Patching these tools to set proper ACLs *when sssd package is installed* doesn't look like a good idea. On the other hand, it's enough to patch libkrb5 to force correct group/permissions of /etc/krb5.keytab, and the patch is simple enough (see http://git.altlinux.org/people/sin/packages/?p=krb5.git;a=blob;f=krb5-1.16-a...)
- also not every filesystem/kernel support POSIX ACLs (think of those NAS devices), but virtually all sensible filesystems know what uid/gid are.
"""
See the full comment at https://github.com/SSSD/sssd/pull/616#issuecomment-405040134
URL: https://github.com/SSSD/sssd/pull/616 Title: #616: become_user: add supplementary groups so ad provider can access keytab
asheplyakov commented: """
become_user() is also used in krb5_child to switch to the user trying to log in to create the ccache with the right permissions.
Yep, calling initgroups in this context is indeed inappropriate. What about adding a new function `become_user_ext`, which adds supplementary groups, and using it where appropriate, for instance, in [server_setup](https://github.com/SSSD/sssd/blob/519354d079731e673244a8e3851e5c5522d1b45e/s...) and [data_provider_be.c:main](https://github.com/SSSD/sssd/blob/1038473e1c9775d1273809c46673fa1475e50937/s... """
See the full comment at https://github.com/SSSD/sssd/pull/616#issuecomment-405041095
URL: https://github.com/SSSD/sssd/pull/616 Author: asheplyakov Title: #616: become_user: add supplementary groups so ad provider can access keytab Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/616/head:pr616 git checkout pr616
URL: https://github.com/SSSD/sssd/pull/616 Author: asheplyakov Title: #616: become_user_ex: add supplementary groups so ad provider can access keytab Action: edited
Changed field: title Original value: """ become_user: add supplementary groups so ad provider can access keytab """
URL: https://github.com/SSSD/sssd/pull/616 Title: #616: become_user_ex: add supplementary groups so ad provider can access keytab
sumit-bose commented: """ Hi,
after rethinking the original issue (keytab access with AD provider) I think the PR is not the best way to solve it. The issue happens when SSSD discovers other domains in the forest at runtime where it wants to check if suitable keys can be found in the keytab. This is the same operation which was already done at startup where SSSD's backend process was still running as root. So instead of checking the keytab directly again it would be easier to check if the configured domain already has the needed information read from the keytab and continue without accessing the keytab again.
In the long run we might even switch to use gss-proxy so that SSSD does not need to access the keytab directly in this code area.
Given that I'll close the PR.
bye, Sumit """
See the full comment at https://github.com/SSSD/sssd/pull/616#issuecomment-769133733
URL: https://github.com/SSSD/sssd/pull/616 Title: #616: become_user_ex: add supplementary groups so ad provider can access keytab
Label: -Waiting for review
URL: https://github.com/SSSD/sssd/pull/616 Author: asheplyakov Title: #616: become_user_ex: add supplementary groups so ad provider can access keytab Action: closed
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/616/head:pr616 git checkout pr616
sssd-devel@lists.fedorahosted.org
-
asheplyakov -
centos-ci
-
fidencio
-
jhrozek
-
sumit-bose