| 1 |
I hope this is not too OT for this list, though it is security-related. |
| 2 |
|
| 3 |
Why is it that Gentoo provides a bin user and group and yet there are |
| 4 |
virtually no packages out there which make use of it? (The only one I've |
| 5 |
found is sys-libs/gdbm.) |
| 6 |
|
| 7 |
I did a little research and found fairly inconsistent results. Neither |
| 8 |
Red Hat nor Debian seem to use it. Solaris and AIX do. But all the Linux |
| 9 |
systems I have checked at least include a bin user; they just don't use |
| 10 |
it. |
| 11 |
|
| 12 |
Finding anything useful about the bin user on Google is difficult |
| 13 |
(imagine how many cgi-bin references there are out there), but here's |
| 14 |
one I did find: |
| 15 |
|
| 16 |
http://publib16.boulder.ibm.com/pseries/en_US/aixbman/security/sysspec_accounts.htm |
| 17 |
|
| 18 |
The bin user account typically owns the executable files for |
| 19 |
most user commands. This account's primary purpose is to help |
| 20 |
distribute the ownership of important system directories and |
| 21 |
files so that everything is not owned solely by the root and sys |
| 22 |
user accounts. |
| 23 |
|
| 24 |
Obviously some executables need to be owned by root or some other user |
| 25 |
because they are setuid, but most of them don't need to be. And of |
| 26 |
course the bin user on Gentoo and others is set to have a /bin/false |
| 27 |
shell, so that no one can log in as bin, and nothing runs as bin. |
| 28 |
|
| 29 |
Additionally, why are executables by default installed with 755 |
| 30 |
permissions? There's really no good reason for them to be writable by |
| 31 |
any user; I am pretty sure that Portage uses an "atomic-replace" when |
| 32 |
merging, i.e. write to a temporary file, then rename to the destination |
| 33 |
file, since after updates I will see some daemons running from deleted |
| 34 |
files (via lsof), and anyway the merge runs as root. |
| 35 |
|
| 36 |
There's also not any good reason I can think of for non-scripts to be |
| 37 |
readable: On the old Red Hat 6.2 box I'm maintaining, most of the |
| 38 |
executables in /bin are owned by bin:bin and execute-only. I am pretty |
| 39 |
sure one of the previous maintainers did this, i.e. it wasn't like this |
| 40 |
out of the box, since there are newer executables that are root-owned |
| 41 |
and 755. Being execute-only does not prevent them from using dynamic |
| 42 |
libraries, either. |
| 43 |
|
| 44 |
Alternatively, if they were owned by bin:bin, they could be |
| 45 |
read-executable for owner and group and execute-only for others, and |
| 46 |
then system administrators could add bin as an auxiliary group for |
| 47 |
potential debugging. |
| 48 |
|
| 49 |
Another potential downside is that it may inhibit bug reporting. For |
| 50 |
example, most GNOME programs will use Bug Buddy if they segfault, and |
| 51 |
Bug Buddy uses GDB to get traceback information, and that might be |
| 52 |
thwarted if the executables were not readable. Although, IMHO, in the |
| 53 |
current default configuration, Bug Buddy is nearly useless because |
| 54 |
Portage strips binaries, so you don't have a symbol table anyway. |
| 55 |
|
| 56 |
Does anyone else have an opinion? Is it worth bothering with the bin |
| 57 |
user? |
| 58 |
|
| 59 |
-- |
| 60 |
Andy Dustman <adustman@×××××××××.edu> |
| 61 |
Office of Information Technology, Terry College of Business, UGA |
| 62 |
|
| 63 |
Computer interfaces should never be made of meat. |
| 64 |
|
| 65 |
-- |
| 66 |
gentoo-hardened@g.o mailing list |
Archives