Hi Sumit. Lost this answer and I've just seen it. That directory (/var/lib/sss/deskprofile/my.domain/myuser) will be only written by SSSD. What fleet commander does is to read files in it and transform that data into the former settings needed to be applied for that user.

Fleet commander is called from SSSD using a dbus call when all the needed files are ready at /var/lib/sss/deskprofile/my.domain/myuser, so fleet commander client is running at root and it should be able to read that information and it will only open the files to read them, not to write (although as fc is running as root would be able to write if needed).

Hope this answers your question.



On Thu, Feb 1, 2018 at 12:48 PM Sumit Bose <sbose@redhat.com> wrote:
On Thu, Feb 01, 2018 at 10:59:23AM +0000, Oliver Gutierrez wrote:
> 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.

Hi Oliver,

thank you for the reply. One topic in this threads was the permissions
of /var/lib/sss/deskprofile/my.domain/myuser. So if I understand you
correctly although you try to not write sensitive data to the profiles
you still think it is a good idea that
/var/lib/sss/deskprofile/my.domain/myuser is only readable by root and
the related user.

What about writing? How should be allowed to create files in the
directory, only root or the user as well? And who should be allowed to
write/modify existing files in the directory?

bye,
Sumit

>
> 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@redhat.com>
> wrote:
>
> > 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
> >>
> > _______________________________________________
> > 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
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org