Well. I think pink unicorns are not a big deal. The problem comes if you
have something like I Love Windows 95 or something like that.
Jokes apart and focusing in your question, we try not to store sensitive
information in any profile. For example, the WiFi and VPN passwords on
NetworkManager connections are removed before storing the profile.
There is other kind of information that can be obtained like the background
image, but that information is stored in a profile that is not public. Only
users with administrative rights in IPA can see that, or the root user in
your machine, because the profiles are downloaded to
/var/lib/sss/deskprofile/my.domain/myuser, and myuser directory is only
readable by me and root.
Fleet commander client takes that information and applies it to your user
usually deploying files at /run/user/$UID, so it is not readable by noone.
In this case I would be more afraid of someone staring at my screen over my
shoulder that can see the pink unicorns flying around :)
On Thu, Feb 1, 2018 at 10:34 AM Fabiano Fidêncio <fidencio(a)redhat.com>
wrote:
On Thu, Feb 1, 2018 at 11:25 AM, Sumit Bose <sbose(a)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(a)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(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org
> _______________________________________________
> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org
>
_______________________________________________
sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org