System-users and-groups?
Koppe
I know this sounds like a newbie-question, but what
does the various system-users and system-groups do?
Which parts of the file-system (directories and files)
could/should they own? Which executables could/
should be set SUID and/or SGID to them? Which
processes could/should be run as these users? Which
users (e.g. root, mail, bin, adm, mailmaster) should
typically belong to which groups?
I of course "know" how these users and groups are
used and what they do, but I don't *know*... What I
really would like, is to see some standard,
recomandation or summary over the common users and
groups on a Linux/Unix system -- how they should be
used (e.g. which files/directories they should own and
which processes they should run). So if anybody knows
of such a document, please point me the way...
+++
AFAIK, a Linux system *must* have at least two users
and two groups -- the root-user and root-group, and
the bin-user and the bin-group... the root-user has
special-privliges hardwired into the kernel, but what
about the root-group? And what about the bin-user (and
bin-group)... does it too have priviliges hardwired
into the kernel?
My main problem is that the use of users and groups
varies hugely between distros... on top of that, there
are a number of users and groups (mostly for various
subsystems like man, halt, sync) that never seems to
be used -- they don't own any files/directories and no
processes are run as them (although there probably
could and should).
I would think it would be desirable to run various
system-processes (daemons) with as low privliges as
possible, and to otherwise restrict access as much as
possible.
+++
Take man...
Shouldn't the man-command be run SUID to the
man-user? Shouldn't the man-pages and assosiate
directories be owned by the man-user and man-group?
Wouldn't it make sense to let some users become
members of the man-group, so they could add, edit or
delete man-pages?
+++
Take the bin-group... on some system, this group owns
the various bin-and sbin-directories and most of the
files (executables) in them (unless the executable is
run SGID and therefor must belong to some special
group). Thus I would think that a normal user made
member of the bin-group, would/could have enough
privliges to install (copy in) or remove simple
commands (e.g. ls, ps, vi; as opposed to larger
packages that would require higher privliges).
Although the files in the various bin and sbin
directories and their files are usually owned by the
root-user, I guess they *could* be owned by the
bin-user -- unless another UID was necessery because
the executable was set SUID.
Though some distros typically uses the root:bin pair,
most uses the root:root pair (as in user:group).
On some distros I have seen the odd daemon running as
the bin-user, but that is rather seldom... aren't
there more daemons that could -- and ought to -- run
with less than root-priviliges?
+++
Then there is the adm-group and user... I assume
it's named from the adm-directory that has since been
moved and renamed to /var/log. I have seen on some
distros that /var/log -- and most of the files under
it -- belongs to the adm-group... so I assume a user
belonging to the adm-group would be able to check the
system's health by looking at various logs.
I would think that the adm-user could run things like
syslog.
+++
I assume that users made member of the root-group can
preform system-tasks with *near* root-users
privliges... but I don't know if it's common (or wise)
to make ordernary users members of this group.
+++
I have know idea what the sys user and group should
own and run, or which users should belong to the
group. I assume *some* part of the file-system (other
than bin, sbin and log) could/should be owned by this
group.
+++
I guess it would be a good idea to let some users
handle things like mail, web and printing -- and
perhaps make a user-account especially for these tasks
(e.g. mailmaster and webmaster) that a user could su
to... and I assume this could be accomplished by
making these users member of the groups handling that
particular system (e.g. mail, www and lpr).
+++
Then there are groups for...
wheel -- real users allowed to use su (to become
root).
shadow -- for programs needing access to
shadowed-passwords.
Various subsytems like mail, lpr, daemon...
For users allowed to use certain systems like cron
and at...
Then there are groups for various devices (e.g. tty,
disk, floppy, snd) to allow certain users -- real,
system or psaudo (like games) -- a more direct access
to devices without root-privliges.
+++
As I said, I've seen how groups and users are used...
and I understand how they are used... but I *really*
would like some standard or recomandation or
description of the various users and groups; and how
they *should* be used.
-Koppe
---
* Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24
The Natural Philosopher
The totality of the historic mess that is users and groups is best
understood forts of all as part of a layered security system, which you
understand, and secondly as an audit trail when hunting down
problems...if a large file owned by 'joe' fills the whole partition, you
know who to go to to consult as to why its there and whether its needed
or not.
That is, as well as restricting *access* to directories files devices
and executables, the user/group system also identifies what users and
processes are doing what in a large system.
The proliferation of odd users and groups has as much to do with that as
with security.
Its customary for every new software package to introduce a new user,
especially if it runs as a daemon, purely so that the daemon can be
instantly recognisable.
A classic example might be MySql, which is allowed to access files that
its USERS never should. And write log files and temporary files that are
not user specific.
So it generally gets its own user and group to do this with..
It would then get started by something with root privileges, or have
enough SUID/GID permissions to change to its own UID/GID when starting.
This isn't a complete answer to a complex question, but perhaps it would
enable you to reduce your question to some more specific examples of
things it doesn't explain..
ibuprofin
On 8 May 2006, in the Usenet newsgroup alt.linux, in article
<1147076158.9...@u72g2000cwu.googlegroups.com>, Koppe wrote:
>Which parts of the file-system (directories and files)
>could/should they own?
No hard-fast rule
>Which executables could/should be set SUID and/or SGID to them?
That very much depends on how the binaries are used/compiled. It is
certain that (for example) /bin/login and /bin/passwd need to be SUID
root because of what they are doing, but what about /bin/ping or
/usr/sbin/sendmail?
>Which users (e.g. root, mail, bin, adm, mailmaster) should
>typically belong to which groups?
With most Linux, root need only "belong" to group "root" because such
group membership is not relevant. 'mail', 'bin', 'adm' tend to belong
to their own group only. I'm assuming 'mailmaster' owns/runs the MTA,
and that may also be in it's own group.
>What I really would like, is to see some standard,
>recomandation or summary over the common users and
>groups on a Linux/Unix system -- how they should be
>used (e.g. which files/directories they should own and
>which processes they should run).
I haven't seen such a recommendation in a long time. Typically, unless you
have some very specific reason to change things, you should keep the ownership
as the distribution installed it. You are quite welcome to make your own
analysis of each binary on your system, and decide what permissions and/or
ownership is appropriate, but have you looked at the size of that task?
>AFAIK, a Linux system *must* have at least two users
>and two groups -- the root-user and root-group, and
>the bin-user and the bin-group...
Were that the case, why the convention to have "system" UIDs below 50 or
100 or similar, and user UIDs above that?
>the root-user has special-privliges hardwired into the kernel, but what
>about the root-group?
Depends on how the binary is written/compiled. Group ownership for a
specific reason isn't that uncommon. And it's not specific to the kernel.
Generally, the user ID tests are written into the binary.
>And what about the bin-user (and bin-group)... does it too have
>priviliges hardwired into the kernel?
Not specific to the bin user, but this may depend on file/device ownership.
>My main problem is that the use of users and groups
>varies hugely between distros... on top of that, there
>are a number of users and groups (mostly for various
>subsystems like man, halt, sync)
The 'halt' (and perhaps 'shutdown') user was a mechanism to allow certain
users (who were given the password) the ability to shutdown the system. Look
at the "login shell" in /etc/passwd for those users, and see that logging in
as that user runs that command. Same is true for user 'sync'. In most
installations I've seen, these accounts are disabled (* in password field)
but a root user could log in as that user in order to run that command - and
may or may not save some keystrokes. I've also seen those accounts reset to
have '/bin/true' as the login shell.
>that never seems to be used -- they don't own any files/directories
>and no processes are run as them (although there probably could and
>should).
Distribution dependent.
>I would think it would be desirable to run various system-processes
>(daemons) with as low privliges as possible, and to otherwise restrict
>access as much as possible.
That is in general what is done.
>Shouldn't the man-command be run SUID to the man-user?
Why? What need do you see?
>Shouldn't the man-pages and assosiate directories be owned by the
>man-user and man-group?
Distribution dependent. If your man command uses /var/catman/ the man
binary may be 'SGID man' to be able to write the formatted man pages to
that directory, but that's about it.
>Wouldn't it make sense to let some users become
>members of the man-group, so they could add, edit or
>delete man-pages?
No.
>Take the bin-group... on some system, this group owns the various
bin-and sbin-directories and most of the files (executables) in them
>(unless the executable is run SGID and therefor must belong to some
>special group).
OK
>Thus I would think that a normal user made member of the bin-group,
>would/could have enough privliges to install (copy in) or remove simple
>commands (e.g. ls, ps, vi; as opposed to larger packages that would
>require higher privliges).
Oh... newbie. Ever wonder why '.' is not commonly in a user's PATH, and
why it should NEVER be in root's? Let's just say that's the result of
decades of experience at universities. One really funny joke is to put
a file in a "common" directory named 'ls-l' or 'mroe' or similar that
ran the 'rm -Rf' command on the user's home directory. Great fun - lots of
laughter - teaches typing skills.
>On some distros I have seen the odd daemon running as the bin-user, but
>that is rather seldom... aren't there more daemons that could -- and
>ought to -- run with less than root-priviliges?
Daemon? Sure - but a lot of that depends on how the binary is written, and
how it is compiled in addition to what the daemon is trying to do.
>I would think that the adm-user could run things like syslog.
[compton ~]$ grep auth /etc/syslog.conf
# Don't log private authentication messages!
*.info;mail.none;authpriv.none /var/log/messages
# The authpriv file has restricted access.
authpriv.* /var/log/secure
[compton ~]$
There might be one reason.
>I assume that users made member of the root-group can
>preform system-tasks with *near* root-users
>privliges... but I don't know if it's common (or wise)
>to make ordernary users members of this group.
That's what 'su' and 'sudo' (and similar) are for. Assume John Doe is in
user 'root' and decides to install an "improved" /bin/login. Or to first
chmod certain files in /boot/ and them remove them. Tracks? What tracks?
>wheel -- real users allowed to use su (to become root).
'info su' the wheel requirement is a BSDism.
Old guy
Menno Duursma
> What I really would like, is to see some standard, recomandation or
> summary over the common users and groups on a Linux/Unix system -- how
> they should be used
(AFAIK and) unfortunately there isn't any.
However the latest LSB (v3.1) states:
"Generally daemons should now run under individual User ID/Group IDs in
order to further partition daemons from one another."
Which to me reads: POLA (at user/group granularity):
http://en.wikipedia.org/wiki/Principle_of_least_privilege
> (e.g. which files/directories they should own and which processes they
> should run).
Ultimately that is up to system administators. However some tighter
defaults in popular distros (and thier packages) would certainly be an
improvement IMO. For instance if 'others' wouldn't be allowed to execute
any suid/sgid executeables, or have access to /dev/dri/cart*, gaining
(further) privileages from a compromised daemon account should be harder.
> So if anybody knows of such a document, please point me the way...
The only one i know of is LSB but that's a bit sparce on the subjest IMO:
http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/tocusersgroups.html
--
-Menno.