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 wrote:
> On Thu, Feb 01, 2018 at 10:59:23AM +, 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
> > wrote:
> >
> > > On Thu, Feb 1, 2018 at 11:25 AM, Sumit Bose 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
> 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
