Quoting Steve Grubb (sgrubb@xxxxxxxxxx): > On Monday 27 July 2009 09:11:33 am Serge E. Hallyn wrote: > > Quoting Steve Grubb (sgrubb@xxxxxxxxxx): > > > On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote: > > > > > I trust you meant to write 0555? > > > > > > > > No, I really mean 005 so that root daemons are using public > > > > permissions. Admins of course have DAC_OVERRIDE and can do anything. > > > > Try the script in a VM and tell me if there are any problems you see. > > > > > > I should elaborate more. The issue is that sometimes there are secrets > > > that root admins have access to that should not be available to > > > semi-trusted daemons. For example, any private keys in /root or /etc. You > > > do not want any daemon that could be compromised to have access to these. > > > So, its safest just to set the permissions to 0005 so that they have no > > > access to /root. > > > > But 0555 will also prevent root without CAP_DAC_OVERRIDE from writing, no? > > True. After some thought, I guess most secrets that a partially trusted root > daemon may attempt to access would be in /root, /etc, /var, and /home. Perhaps > those are the ones that need the extra tight permissions? Well 0555 vs. 0755 is already 'extra tight' for /bin itself, no? > > Using 0005 will mean root also needs CAP_DAC_OVERRIDE to read/execute, > > which seems a bit much. Suddenly it needs extra privilege if i just want > > it to be able to execute /bin/date. That actually seems less secure in any > > real system. > > # ls -l /bin/date > -rwxr-xr-x 1 root root 69296 2009-03-02 08:57 /bin/date > > The file is 0755 and therefore is executable by anyone. DAC_OVERRIDE is not > needed for anything but writing to the file as in "yum update". But you said you were making /bin 0005, in which case users other than root could access /bin/date, but root itself could not without CAP_DAC_OVERRIDE (as tested by: mkdir delme chmod 005 delme ls delme Permission denied ) -serge -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
