On Thu, Feb 1, 2018 at 11:25 AM, Sumit Bose <sbose@redhat.com> wrote:
On Wed, Jan 31, 2018 at 10:01:15AM -0500, Simo Sorce wrote:
> On Wed, 2018-01-31 at 14:55 +0100, Fabiano Fidêncio wrote:
> > Sumit,
> >
> > On Fri, Jan 26, 2018 at 9:01 PM, Sumit Bose <sbose@redhat.com> wrote:
>
> [..]
>
> > I'll leave the other 2 questions to Simo. :-)
> >
> > I wonder if there is a chance that e.g. a signal can force to backend to do
> > > something else when running with the changed euid?
>
> If I am not wrong we pipe all signals back quickly into tevent events,
> so signals should not cause issues. This should be carefully checked
> but I would be surprised if any of our signal handlers do any I/O
> besides triggering a tevent via pipe, it is not recommended to do that
> anyway.
> On whether seteuid influences the delivery of signals I am not 100%
> sure, but I think only a real uid change will affect that, not the
> effective uid. (on the receiving side which is what we care about).
>
> So I think we are OK here.
>
> That said, are we sure we retain CAP_SETUID ?
>
> > > Is there something you do not like about the approach of PR498?
>
> Here my comments from the tracker:
>
> FWIW,
> I see nothing wrong in keeping CAP_DAC_OVERRIDE, the process is running
> as root and can impersonate users at any time so removing this
> capability does not change the security stance.
>
> However it may make some errors less severe if people use seteuid() to
> change the effective id of the user, because then the process cannot
> alter data or access compartmentalized data by mistake.
>
> Opening permissions on the files negates the benefit of using seteuid()
> so it is the least desirable way to handle this "issue".

Thank you for the explanations, so I'm fine with using seteuid()/setegid().


I've updated the design page and send the patches to FleetCommander developers so they can test it.
I'll update the github PR as soon as I have their feedback.

So, summing up, thanks for the inputs!
 

Fabiano, nevertheless I'd like to ask some questions about the profile
files, please let me know if I should better ask the Fleetcommander
developers.

Is it expected that the user can change the data in the file? Or is it
the other way round that it would be better that the user only has
read-only access so that the admin can force some settings?

I'd say not. So, maybe going for a read-only solution would be better.
Here, I'll confirm this with Oliver.


Is it possible that there is any sensitive information in the profile
files or would it be ok if anyone can read it? (hm, while writing the
question I started wondering if I would be happy if everyone knows that
my desktop background is pink_unicorns.jpg?).

This is a quite good question and I'll redirect it to Oliver and get back to you as soon as I have both answers.
 

bye,
Sumit
>
> HTH,
> Simo.
>
> --
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
> _______________________________________________
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org