On 03/05/2015 10:15, marcxdv@??? wrote:
> 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.

I am starting to wonder whether I really am that bad at expressing
myself. I'll try to clarify.

* You said autocompletion with stat() would be slow. Fair enough.
(although profiling this would be interesting. How slow is "slow" ?
You mention smartphones or wearables, but how often do people run an
interactive shell on those ?)
* I tested my zsh autocompletion, and observed that it does not
perform stat(), thus leaning your way. OK, 0700 do not hide binaries
from autocompletion, so in the current world, my suggestion does not
work.
* I then argue that in the current world, autocompletion is not
reliable, because since it does not stat(), it cannot hide filenames
the user cannot execute, such as a 0644 file. What your autocompletion
is currently printing is an approximation of the programs you can run,
not an accurate list - in other words, merging /bin and /sbin would not
"break" autocompletion, because it is already "broken". You are just
not seeing it because the (good) convention of not putting anything
non-executable in /bin is widely followed - but the whole mechanism
is simply relying on a convention, and stricto sensu you should not
entirely trust it. The only way to make autocompletion reliable
would be to stat() every file it scans. Which may or may not be too
slow in practice.

Note that I do not actually suggest merging /bin and /sbin. I think
that it would be too much effort for too little gain. I only said that
if a directory structure was designed today, without the weight of
historical practice and convention, then /sbin and /usr/sbin would
simply not be needed.

> * 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.

OK, thanks for clarifying. This isn't security through obscurity
indeed. However, you could achieve the exact same result by putting
this tool in /usr/bin - or anywhere else - with chown root:admin
and chmod 2750 - you don't need a separate directory to hold binaries
you only want a specific group to run.

And chmodding /usr/sbin is less flexible than chmodding individual
executables, because all the executables you put into /usr/sbin will
only be accessible to group admin, whereas chmodding individual
executables allows you to select which group, or which user, will
be able to run them. So if I wanted to restrict a binary's
executability to a group, I would chmod that binary regardless of
its location; I would not set up a specific location to host
restricted binaries.


> 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).

I was referring to the lack of an r bit on the /usr/sbin *directory*,
which only hides file names, and is only useful if all your files
have unpredictable names (which is usually not the case at all for
executables).
The real security in your design does not come from the lack of an
r bit, but from the lack of an x bit on that directory, which makes
the files non-accessible.


> 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.

Sure, as an informational tag, /sbin makes sense. I agree that it
is convenient. But more effort must be put into trimming an image
if you want real security. Drop the security argument and I'm with
you.


> Mount has an excuse to be a run by a user, given that fstab
> supports the "user" mount option.

I remember 10ish years ago, mount was actually /sbin/mount.
It migrated to /bin at some point, probably, as you say, when the
"user" mount option was added. I personally think that moving
executables between places is a bad thing, and one of the reasons
why I'm not a fan of /sbin.
Because, how long before "route" can also be run by users ? If
users can mount their own filesystem, it's only a matter of time
until they can, say, run their own container with a virtual IP.
As Unix evolves, so does the distinction between admin-only and
user-available, and absolute paths break.

Since we have PATH anyway, I don't really mind /sbin, but I
maintain that it made much more sense in the 70s than it does today.

--
Laurent