Package: general
Version: 20001222
Severity: important
Hi,
I feel that there exists a general confusion among some Debian developers as
to what user ids such as 'nobody' should be used for. I suggest that the
policy be updated with relevant advice.
As I see it, 'nobody' should be a user that owns no files and has no
privileges; thus, if a service running as 'nobody' were to be compromised,
the attacker wouldn't gain the ability to change any files.
However, some packages seem to contain or create files owned by 'nobody' or
the 'nogroup' group (for example, the buffers of distributed-net-pproxy are
owned by nobody.nogroup).
www-data is another user that shouldn't own files (so that breaking into the
webserver won't allow the attacker to replace files on the system); sadly,
Roxen needs to own its own configuration files for the web-based
configuration interface to work.
'daemon' is another user that is, in my opinion, often abused. For example,
portmap, the 'at' daemon, lprng and the distributed-net client all run under
the 'daemon' uid. There is no need for these to be able to affect each other
in any way (e.g. send each other signals). All of these should probably run
under their own (dynamically allocated) user id.
A quick search for files owned by 'daemon' turned up the following:
/var/state/mon
/var/lib/distributed-net
/var/lib/distributed-net/distributed-net.ini
/var/lib/distributed-net/distributed-net
/var/lib/distributed-net/buff-out.rc5
/var/lib/distributed-net/buff-in.rc5
/var/log/mon
/var/run/lprng/lpd.printer
/var/run/mon
/var/spool/cron/atjobs
/var/spool/cron/atjobs/.SEQ
/var/spool/cron/atspool
and any number of files and directories under /var/spool/lpd/.
Obviously, the portmapper has no need to write to any of these; however, if
an attacker were to compromise it and gain its privileges, they could break
unrelated software (like lprng or distributed-net) on the system, perhaps
even leading to privilege escalation.
Imho 'daemon' is a user that exists mainly for historical reasons, reminding
us of times when security wasn't as much an issue as it is now.
Basically, if two processes have no need to ever send each other signals or
write to the same files, they probably shouldn't run under the same user id
(except if they need to run as root, of course).
Now that capabilities exist in the Linux kernel, Debian packages should
probably make use of them more often; perhaps even fewer programs would need
to run as root do their work.
Most packages that contain programs run 'at system level' ('daemons') should
probably create their own user id that the program can run under (luckily,
many packages already do this).
I file this report as 'important' because the way things are now, a
vulnerability in an unprivileged (non-root) service can be used to
compromise other unrelated services running under the same userid.
Regards,
Andrew
--
Andrew Korn (Korn Andras) <[EMAIL PROTECTED]>
Finger [EMAIL PROTECTED] for pgp key. QOTD:
Dogs come when you call. Cats have answering machines.
-- System Information
Debian Release: woody
Kernel Version: Linux utopia 2.4.0-test11 #15 Mon Dec 4 15:10:19 CET 2000 i686
unknown
