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