MAJOR hole in 5.0

Dagmar d'Surreal dagmar.wants at
Fri Sep 26 12:07:56 PDT 2003

On Fri, 2003-09-26 at 09:36, Daniel Roethlisberger wrote:
> Some people suggested that the user 'nobody' does not need to be there.
> I believe that is not true for some/most systems. The user 'nobody' is
> traditionally a non-priviledged user which owns no files (running Apache
> as 'nobody' is abuse of the rationale behind it, and thus considered
> harmful). Some daemons default to using 'nobody' when dropping
> priviledges in order to do unpriviledged work.

Name some.  Everything recent and sane does not, and even old code tends
to be configurable.  Most folks figured out that having more than one
thing using the nobody role account was a bad idea in the early 90's.

> Of course it's possible
> to force such programs to use another user than 'nobody' (runtime
> options, ./configure options, or even patching the source), [...]

Usually these are run-time configuration options, and when they're not,
they're not for some specifically stated reason (like suexec's caller

> [...] but I
> strongly believe it is still a good idea to have the user 'nobody'
> around, just in case you missed one. [...]

Security work should never be done with assumptions like that in place. 
You either know where your UIDs are and what they're for _at all times_
or you're basically pissing into the wind when you make changes.  It's
not like the typical system has so many role accounts in use that you
can't keep track of them all.

> It certainly needs no shell, no
> password and no home directory, but it should be kept around. It does
> not reduce the security at all, as all you can do is setuid() to it from
> root, which you can do to any numerical UID anyway. As long as you have
> no files owned by 'nobody', there's no risk involved.

"That which is not explicitly allowed, is denied by default".

Unless you have an explicit and stated need for that UID to be there, it
should _not_ be there, period.

> On an afterthought, removing the user 'nobody' could in theory even
> reduce security, as some (admittedly badly designed) programs might not
> drop priviledges if no user 'nobody' is around. But this is getting
> increasingly off topic now...

Not a chance.  Either the software is going to be switching to a
_specific_ uid or it's not even trying.  Not being able to change
uid/euid should by sane and reasonable software be considered a critical
error and the program should _complain and exit_, not just fail to drop
privileges with or without comment.  Code that lets this sort of error
just slip past _should not be run_.
The email address above is phony because the people making archives of list
traffic publicly available on the web aren't taking measures to protect the
email addresses from filthy spammers.  
              AIM: evilDagmar  Jabber: evilDagmar at

More information about the lfs-security mailing list