Unix administration - Rookie needs some help

Author

Rookie needs some help

odgreen1

2006-03-06, 5:54 pm

Hey All,

I'm just starting my career in information security and have already
found that I have quite a few questions concerning UNIX security and
account setup.

Here is my first question(s):

1. There are several accounts that seem to be default on all UNIX
systems or on certain UNIX platforms (i.e. SUN, AIX, HP, etc). What I'm
trying to do is figure out what the following accounts are used for:
listen
nobody
nobody4
noaccess

I've done some surfing and found vague answers, but I'm looking for a
little more detail. So far, all I've learned is that these are no login
IDs, but in my line of work we are still required to maintain
registration on all of these and have to come up with a detailed
business justification for these.

Can anyone give me an explanation or point me to a link that would
provided detailed info for these IDs?

Thanks,
TD

Dave Hinz

2006-03-06, 5:54 pm

On 6 Mar 2006 11:13:00 -0800, odgreen1 <tbdonovan@express-scripts.com> wrote:
>
> I'm just starting my career in information security and have already
> found that I have quite a few questions concerning UNIX security and
> account setup.

Welcome!

> What I'm
> trying to do is figure out what the following accounts are used for:
> listen

Dunno.

> nobody
> nobody4

These two are what root's ID will be mapped to from a remote system.
Say you're mounting a share from a remote system. You're root on the
client, the files are owned by root on the server. But, you don't get
them, because from the server's perspective, you're "nobody" (or
"nobody4"), not root.

Goal there is to prevent Joe User from putting a unix box of some sort
on your network, being root on there, and accessing files owned by root
on an nfs server elsewhere.

> noaccess

Dunno.

Dave Hinz

Doug Freyburger

2006-03-06, 5:54 pm

Dave Hinz wrote:
> odgreen1 wrote:
>
>
> Welcome!
>
>
> Dunno.

In general, nologin accounts exist so programs can run with their
UID not root, and/or to have someone identifiable own files. In the
case of "listen", it's a System V service having to do with
listening for print queue requests. I figure it is different from "lp"
because the System V print spooler is different from the BSD
print spooler.

>
> These two are what root's ID will be mapped to from a remote system.
> Say you're mounting a share from a remote system. You're root on the
> client, the files are owned by root on the server. But, you don't get
> them, because from the server's perspective, you're "nobody" (or
> "nobody4"), not root.
>
> Goal there is to prevent Joe User from putting a unix box of some sort
> on your network, being root on there, and accessing files owned by root
> on an nfs server elsewhere.
>
>
> Dunno.

Overlap with nobody. I get the impression it's another of those
overlaps between old SysV and old BSD being gratuitously different.

Michael Paoli

2006-03-07, 5:54 pm

(Followup-to: comp.security.unix)
odgreen1 wrote:
> I'm just starting my career in information security and have already
> found that I have quite a few questions concerning UNIX security and
> account setup.
>
> Here is my first question(s):
> 1. There are several accounts that seem to be default on all UNIX
> systems or on certain UNIX platforms (i.e. SUN, AIX, HP, etc). What I'm
> trying to do is figure out what the following accounts are used for:
> listen
> nobody
> nobody4
> noaccess

These typically exist to be used as IDs having little, "no", or quite
limited privileges. E.g. when one wants an ID that should own
precisely nothing on any of the file systems on a system, one might
have an ID specifically for that purpose, so that daemons, or other
processes that shouldn't own anything and should have no unusual
privileges regarding file access, they can run with the appropriate
suitable ID. There may also be a significant number of such IDs.
Most notably to isolate them from each other - e.g. so that if a
process under one ID is corrupted/compromised, it can't directly
impact the other IDs (e.g. can't signal those processes, access
their memory, or other resources via proc file system or other means,
etc.), and it's more likely any problem can be tracked back to the
responsible service/process/program via the ID. This is also a
reason why many network services will each have their own IDs. IDs
are also sometimes used to have some type of privilege, but less than
superuser (root). Again, there may be many such IDs, for purposes of
isolating them from each other. Removing IDs doesn't necessarily
enhance security, and possibly can cause problems, break things, or
weaken security. If an ID is properly locked down and secured, it
should not pose additional security risks. Ye olde C2 security
requirements actually require that IDs not be removed, but that
instead they be permanently "retired"/deactivated (most notably this
leaves a better audit trail, as the UID <--> login mapping will
always persist and be consistent when C2 is strictly adhered to).

E.g. here's a short list of some special-purpose IDs that may exist on
some systems:
adm
alias
aptproxy
asg
audit
auth
backup
bin
bind
cron
daemon
Debian-exim
dos
faxmaster
fetchmail
ftp
games
gdm
gnats
gopher
identd
informix
ingres
irc
list
logcheck
lp
mail
majordom
man
messagebus
mmdf
msql
netplan
network
news
nobody
ntop
nuucp
operator
oracle
partimag
postgres
proxy
qmaild
qmaill
qmailp
qmailq
qmailr
qmails
rwhod
saned
smmsp
snort
sshd
sslwrap
sync
sys
sysinfo
telnetd
tftpuser
uucp
www-data