[SSSD] [PATCH] Move ccache operations to krb5_child, allow the krb5_auth code to run unprivileged

Simo Sorce ssorce at redhat.com
Thu Nov 6 15:28:02 UTC 2014


On Wed, 5 Nov 2014 22:34:50 +0100
Jakub Hrozek <jhrozek at redhat.com> wrote:

> On Wed, Nov 05, 2014 at 06:36:06PM +0100, Jakub Hrozek wrote:
> > On Fri, Oct 31, 2014 at 06:00:59PM +0100, Jakub Hrozek wrote:
> > > On Tue, Oct 28, 2014 at 03:13:37AM +0100, Jakub Hrozek wrote:
> > > > Hi,
> > > > 
> > > > attached are patches that apply on top of my previous
> > > > ldap_child and selinux_child patches. The complete branch
> > > > (including tests I'm still working on) can be inspected here:
> > > >     https://fedorapeople.org/cgit/jhrozek/public_git/sssd.git/log/?h=nonroot
> > > > 
> > > > Simo, Sumit, I added you to CC directly, b/c I suspected you
> > > > wanted to be included in larger krb5_child changes..
> > > > 
> > > > Below are patch descriptinons of the individual changes.
> > > > 
> > > > [PATCH 1/6] BUILD: Install krb5_child as suid if running under
> > > > non-privileged user If sssd_be is running unprivileged, then
> > > > krb5_child must be setuid to be able to access the keytab and
> > > > become arbitrary user.
> > > > 
> > > > 
> > > > [PATCH 2/6] KRB5: Drop privileges in the child, not the back end
> > > > In future patches, sssd_be will be running as a non-privileged
> > > > user, who will execute the setuid krb5_child. In this case, the
> > > > child will start as root and drop the privileges as soon as
> > > > possible.
> > > > 
> > > > 
> > > > [PATCH 3/6] KRB5: Move ccache-related functions to krb5_ccache.c
> > > > Add a new module krb5_ccache.c that contains all ccache-related
> > > > operations. The only user of this module shall be krb5_child.c
> > > > as the other modules will run unprivileged and accessing the
> > > > keytab requires either privileges of root or the ccache owner.
> > > > 
> > > > This patch only /moves/ code, the changes will come in later
> > > > patches.
> > > > 
> > > > 
> > > > [PATCH 4/6] KRB5: Move checking for illegal RE to krb5_utils.c
> > > > Otherwise we would have to link krb5_child with pcre and
> > > > transfer the regex, which wold be cumbersome. Check for illegal
> > > > patterns when expanding the template instead.
> > > > 
> > > > 
> > > > [PATCH 5/6] KRB5: Move all ccache operations to krb5_child.c
> > > > The credential cache operations must be now performed by the
> > > > krb5_child completely, because the sssd_be process might be
> > > > running as the sssd user who doesn't have access to the ccaches.
> > > > 
> > > > src/providers/krb5/krb5_ccache.c is still linked against
> > > > libsss_krb5 until we fix Kerberos ticket renewal as non-root.
> > > > 
> > > > Also includes a new error code that indicates that the back end
> > > > should remove the old ccache attribute -- the child can't do
> > > > that if it's running as the user.
> > > > 
> > > > 
> > > > [PATCH 6/6] KRB5: Do not switch_creds() if already the
> > > > specified user The code didn't have to handle this case
> > > > previously as sssd_be was always running as root and switching
> > > > to the ccache as the user logging in.
> > > > 
> > > > Also handle NULL creds on restore_creds() in case there was no
> > > > switch. One less if-condition and fewer indentation levels.
> > > > 
> > > > Thank you for the review.
> > > 
> > > Hi,
> > > 
> > > attached patches fix make distcheck issue. There are no changes
> > > in the code itself.
> > 
> > Hi,
> > 
> > attached are rebased patches. Again, there is no change in the code
> > itself.
> > 
> > I'm still looking for a reviewer ...
> 
> Simo,
> 
> in this thread are the patches I pinged you about earlier today on
> IRC. I'm sorry I wasn't able for interactive discussion today, but if
> you have the time, do you agree with the general direction the
> patches are taking?
> 
> I understand you don't have the time for testing etc. but an
> architectural blessing would help as well.
> 
> Thanks!

Comments sent to the list per patch, I think I have no other comments
on the patchset.

Thank you,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the sssd-devel mailing list