Hello again > >> 0700 for root-only binaries would hide them from your shell's > >> autocompletion. > > > >Which would be lots of stat() system calls. > > If a shell doesn't make them, then it doesn't verify that a file is > executable either. (I just checked with zsh: it doesn't indeed.) > Sure, few people will install non-executable files in PATH search > locations, but if autocompletion doesn't guarantee that a filename > it prints will be executable, then it shouldn't be relied on, and > it's not a good argument for /bin and /sbin separation.
So you have just argued that to hide things from autocompletion, one should make things 0700. We have also established that for this scheme to work the shell needs to do a stat() *for* *each* *candidate* executable. But the my /bin/bash does not do a stat() - which is sensible, cause that would be slow. And I couldn't parse if your zsh does or does not. So your proposed solution does not work for most users. So then you say one shouldn't rely on the autocompletion, because your advice (of merging /bin, /sbin and then marking user-uninteresting executables 0700) will make that mechanism unreliable, where it was quite reliable before. So your solution breaks autocompletion. > >Also on paranoid systems /sbin and /usr/sbin can itself be made 0700 or > >0750, so that random users can't even work out what admin commands might > >be there (hide suid exploits) > > I don't support security through obscurity, and you shouldn't either. Security through obscurity is a term often misunderstood. It states that knowledge of the implementation should not allow one to break the access control/restriction. The example I listed does none of the above. Here are the steps: * You have say a setgid executable which probably isn't perfectly secure. You trust your admin crowd to run it, but maybe not a php script which has escaped apache. * So you put it into /usr/sbin and do chmod 750 /usr/sbin chgrp admin /usr/sbin * And now if an exploit for said setgid tool becomes available then the php script won't be able to run it. There is no knowledge of how this mechanism works which would allow an attacker to bypass it. And in general, the R bit on files is there to hide data. If you confuse that with obscurity then there would be no confidentiality at all (and confidentiality, along with availability and integrity are what make up security). > >Or /sbin can be deleted/omitted entirely on containers/virtual images > >where all admin has been done already. > > People who tailor images with exactly the binaries they need will do > it regardless of the location of those binaries. Note I didn't say exactly, I implied it was a cheap option to give cp/tar/rsync to not build the full image and thereby improve the security and reduce the size of the image. Selecting packages and files individually is a lot more effort. Think about /sbin as a "tag" on the executable saying "probably not interesting to a normal user". This information isn't kept elsewhere, and so automating this by other means isn't that easy. > If you don't need > /sbin/route, you probably don't need /bin/mount either. Mount has an excuse to be a run by a user, given that fstab supports the "user" mount option. If that is a good idea or not is unclear. But this discussion relates to the quality and assignment of the tag "not interesting to a normal user", you are arguing for abolishing that tag entirely. More meta-information under your own (not corporate/government ;-) control is typically a good thing, especially if it has been compiled already. Assume that we merge bin and sbin: Chances are in some years some clever spark will then abuse posix labels to tag executables as "for admin (historic sbin)" and everybody will think this is a big breakthrough. > >So there are very good reasons for keeping the classic/standard layout. > > The reasons you gave so far are pretty minor. I listed concerns relating to autocompletion and security which are important to me regards marc _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
