On 03/05/2015 10:15, marc...@welz.org.za 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
