Re: RfD: documentation for statically assigned uid and gid
On Thu, Jun 01, 2000 at 07:44:03PM +0000, Marc Haber wrote:
> As far as I know, there is no "official" document that describes what
> the statically allocated users and groups on a Debian system do, gives
> rationales for their existence and suggests what to do with them. I'd
> like to see such a document (maybe as part of the policy?) and have
> written a description as I understand the users and groups.
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.
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.)
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.
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.
> 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 ;)
> www-data:x:33:33:www-data:/var/www:/bin/sh
> uid for web server software.
_Not_ the owner of static Web content files!
> bin:x:2:
> sys:x:3:
> existing for historical reasons, some programs won't run without these
?!
> 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.
> 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.
> 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.
> 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.
Andrew
--
Where is the innovation? Microsoft, mostly.
- Rob Pike, "Systems Software Research is Irrelevant"
http://www.cs.bell-labs.com/cm/cs/who/rob/utah2000.ps
Reply to: