[SSSD] Config file ownership and cwrap tests

Simo Sorce simo at redhat.com
Thu Jan 15 18:16:10 UTC 2015


On Thu, 15 Jan 2015 19:43:18 +0200
Nikolai Kondrashov <Nikolai.Kondrashov at redhat.com> wrote:

> On 01/15/2015 06:41 PM, Simo Sorce wrote:
> > On Thu, 15 Jan 2015 12:39:35 +0200
> > Nikolai Kondrashov <Nikolai.Kondrashov at redhat.com> wrote:
> >
> >> On 01/14/2015 05:00 PM, Nikolai Kondrashov wrote:
> >>> On 01/14/2015 04:48 PM, Simo Sorce wrote:
> >>>> On Wed, 14 Jan 2015 16:08:33 +0200
> >>>> Nikolai Kondrashov <Nikolai.Kondrashov at redhat.com> wrote:
> >>>>> On 01/13/2015 02:31 PM, Nikolai Kondrashov wrote:
> >>>>>> Hi everyone,
> >>>>>>
> >>>>>> I have a bit of a chicken/egg problem with implementing cwrap
> >>>>>> tests.
> >>>>>>
> >>>>>> Sssd currently requires the config file to belong to root.
> >>>>>> However, that is not possible to arrange when running under a
> >>>>>> regular user, in cwrap tests. Even though uid_wrapper fakes
> >>>>>> running under root, the created files still belong to the real
> >>>>>> user.
> >>>>>>
> >>>>>> I see two ways out of this: either run under fakeroot, or allow
> >>>>>> the config file to (also?) belong to the user sssd is
> >>>>>> configured to run under (target user).
> >>>>>>
> >>>>>> While fakeroot will likely work, to me it seems like sweeping
> >>>>>> the problem under the rug. The second option seems a bit more
> >>>>>> natural, especially considering that the CDB file is explicitly
> >>>>>> chown'ed to the target user, anyway.
> >>>>>>
> >>>>>> Now, since the target user can be configured both at the build
> >>>>>> time *and* in the configuration file itself, we'll need to
> >>>>>> verify file ownership *after* reading it. Or, can we maybe move
> >>>>>> user specification to command-line option?
> >>>>>>
> >>>>>> What do you think?
> >>>>>
> >>>>> Simo, do you have any thoughts on this?
> >>>>>
> >>>>> It is blocking my cwrap LDAP integration test implementation.
> >>>>
> >>>> Uhmmm though problem, I think, for this very special case, we may
> >>>> want an env var that allows the code to relax
> >>>> permission/ownership checking on the config file.
> >>>
> >>> Would there be a problem if we allow sssd.conf to belong to the
> >>> user we're running under, as well? The daemons run under that user
> >>> and CDB file is chowned to it anyway.
> >>
> >> Simo, do you have anything against this? I.e. allowing sssd.conf to
> >> belong to sssd.sssd as well as to root.root?
> >
> > The reason why the file is owned by root.root is so that the
> > unprivileged components can't touch it.
> >
> > Allowing sssd.sssd to own the file defeats this measure, so I do not
> > really like it as the standard behavior, unless we decide we stop
> > checking sssd.conf ownership and just let the admin do what they
> > think is better.
> >
> > If we do the latter then we can simply turn the check from a
> > failure to a warning and we just ignore the warning in the tests.
> 
> Got it, thank you Simo. However, wouldn't the unprivileged processes
> still have most of the information from the configuration file?

The problem is not about reading info, the problem is not being able to
write it back and affect other services in a privilege escalation
attack or similar.

Simo.

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



More information about the sssd-devel mailing list