On Thu, Jun 01, 2000 at 09:31:03PM -0400, Andrew Pimlott wrote: > Great, and thanks! > > I agree that this should be incorporated into policy, not just be a > documentation file. I further think that, using this as a starting > point, Debian should attempt to describe _precisely_ what sorts of > files should be owned by each user and group, what permissions those > files should have, and what sorts of programs should run as each. > This would help us determine where we can better use users and > groups to follow the principle of least privilege. definitly, there are some cases of dubious permissions being set (/var/www) at times, and some users misunderstand the groups. for example there was a user on -user explaining that they could not play CDs so he added himself to group disk since his CD device (/dev/hdc) is owned by group disk. obviously ordinary accounts with group disk is a horrible thing to have... www-data is also a very misunderstood group. > See, for an example of why this would be useful, the debian-devel > thread from January of this year, with the subject "why are > files/directories owned by www-data !?". (I see now that the poster > is familiar with this issue, but it's worth emphasizing.) that was me ;-) and i have checked this again and found that NEW installs of apache create /var/www owned by root.root mode 0755 unless it already exists. however the log files (/var/log/apache/*) are still chowned/chmoded to www-data.www-data mode 0664 by cron. which i consider wrong, the logs are written by the root owned apache process not the unprvileged children so making the logs writable by www-data only allows an attacker to destroy your logs if they break on of the apache children. > FWIW, the last time I checked policy, I believe only a handful of > users and groups were mentioned at all, and most only in passing. yup > Some comments on specific users and groups: > > > daemon:x:1:1:daemon:/usr/sbin:/bin/sh > > uid to run various non-root daemons (for example the portmapper). > > Giving each such daemon its own user might be a win. Today, one > compromised daemon process can kill all other daemon processes. well you can go overboard... it really depends on how bad it would be if all daemon owned processes were killed, or fall under hostile control. my basic idea on the matter is if the daemon needs to own or write files it should have its own uid. otherwise daemon/nobody are probably ok. depending on the importance. it would be nice to have some standard on this, what should be run as nobody and what should be run as daemon? > > sync:x:4:100:sync:/bin:/bin/sync > > login shell /bin/sync allows a user without account on that system to > > sync disks from the console. > > Are you joking? Wait--let me guess the rational: Someone needs to > shut down all the machines in a lab, but doesn't have root access to > them, so he logs into them as sync righ before hitting the power. > Don't tell me if I'm wrong; I'd like to imagine this ;) i read about this in "A Practical Guide to Unix and Internet Security" under things NOT to do ;-) apparently some time ago commercial unix vendors would create accounts like this that only execute a single program, many of which were uid 0 and all had a null password. the idea is to allow one to shutdown the machine by logging in as shutdown, or sync the disks by logging in as sync etc. there were many dubiously creative things various vendors did. the problem comes that many programs in the day had shell escapes built in (many still do today!) so one could login to a nice uid 0 account and use a shell escape to get root! > > www-data:x:33:33:www-data:/var/www:/bin/sh > > uid for web server software. > > _Not_ the owner of static Web content files! or apache logs! > > bin:x:2: > > sys:x:3: > > existing for historical reasons, some programs won't run without these > > ?! actually these are still used on some unix systems, on my OpenBSD box for example: $ ls -l /usr/bin/passwd -r-sr-xr-x 1 root bin 24576 Nov 1 1999 /usr/bin/passwd $ ls -l /bin/sh -r-xr-xr-x 3 root bin 307200 Nov 1 1999 /bin/sh $ ls -l /usr/bin/passwd -r-sr-xr-x 1 root bin 24576 Nov 1 1999 /usr/bin/passwd $ ls -ld /bin drwxr-xr-x 2 root wheel 1024 Nov 1 1999 /bin $ i don't really see the advantage of using gid bin in this manner but openbsd does it quite consistently. long ago binaries were owned by bin, but that of course does nasty things to NFS root_squash... > > adm:x:4: > > log files are group readable to adm. Include people who should be able > > to read log files. > > Many log files are not readable by group adm. Policy would help > here. yes it would, its already pretty consistent already, though some logs are world readable that i think should not necessarily be (but i may be more paranoid then others) > > disk:x:6: > > disk device nodes are group accessible to disk. Programs that need > > access to them are sgid disk. > > For groups like this (disk, audio, video, dialout), it would be cool > if adduser could run in an interactive mode that explained the > implications of each group and let the admin select which ones a new > user should belong to. and scream loudly when a uid 1000+ uid is added to group disk ;-) or just good documentation for users to ignore. > > src:x:40: > > Include people who should be able to write /usr/src in this group. > > What is its intended use? > > And why are not /usr/src, and packages that install there, writable > by group src? Policy would help. i have a user account with primary group src that i use for all local compilation, that way the source code is still protected from my normal uid and all users can still see source code. i never compile anything as root. > > staff:x:50: > > Include users who should be able to write to /usr/local and /var/local > > Again, it's not like this by default. um yes it is, i know because i had to undo it on each and every debian potato install i did ;-) i personlly don't care much for the staff writable /home /usr/local /var/local directories. the idea of user accounts having write permission to directories in all users' PATH gives me the willies. maybe if you had a dedicated user account for managing this stuff its ok, but adding real users to group staff is a bad idea IMO. (remember that *nix is resistent to much of the virii/trojans that MS land suffers due to strict file permissions) just for some interest OpenBSD has some other uses for some of these uids, for example: uid/gid operator: $ ls -l /dev/wd0* brw-r----- 1 root operator 0, 0 Mar 28 23:04 /dev/wd0a brw-r----- 1 root operator 0, 1 Mar 28 23:04 /dev/wd0b brw-r----- 1 root operator 0, 2 Mar 28 23:04 /dev/wd0c brw-r----- 1 root operator 0, 3 Mar 28 23:04 /dev/wd0d brw-r----- 1 root operator 0, 4 Mar 28 23:04 /dev/wd0e [...] the backup program is supposed to be run with group=operator or user=operator it seems. the read only devices i find an interesting point, unattended non-root backup through direct device files is a good plan but who does unattended restore operations?? so why does the raw device files need to be group writable? seems like an extra risk there. $ ls -l /sbin/shutdown -r-sr-x--- 1 root operator 151552 Nov 1 1999 /sbin/shutdown user operator may shutdown without being root. user nobody has primary group nobody, and a nogroup group also exists. named exists by default (bind is chrooted by default too) they have a `www' user that the httpd runs as. they have a sys group but i cannot find any use of it. many other groups debian has already... -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpRYAd3lc6r4.pgp
Description: PGP signature