|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
Unix Groups administration
Unix groups, while a powerful concept, are subject to two annoying limitations:
- First, groups cannot contain other groups as members (no nesting).
- A second problem is
the limit imposed by Unix on the maximum number (usually 16 or 32) of groups
associated with an individual user or process. That make fine grain
separation of data space using groups difficult (but not impossible).
Yet another limit on group memberships is imposed by the ubiquitous presence
of NFS. The NFS RPC protocol can truncate group access credentials to even fewer
than the number supported by the underlying OS. Users may encounter problems
accessing NFS mounted files by virtue of being in too many groups on one machine
or in too few on another.
The modern way to administer groups in Unix is to have each user belong own
primary group (with GUID equal to UID). I think this was pioneered by Red
Hat.
Composite groups include:
- wheel primary system administrators (can be used with sudo to grant
privileges to switch to root)
- staff
- dba
- operator
and several others.
Home directories should be generally be "group averse" with permissions 750 and owned by user:root.
Two domains scheme:
- high security for all system (owned by root programs by using special
filesystem or write protected filesystem /usr/sbin, usr/bin
- Everything else.
The preservation of identity (UID and GID) as a desired
property of Unix group administration. The problem of group mapping created
interesting security vulnerabilities when you transfere files from one computer
toanother as root.
Ruby script
Silk Tree propagate /etc/passwd and
/etc/group files from a master to a list
of hosts via SSH. Neither the sending nor the receiving end connect to each
other as root. Instead there is a read-only sudo sub-component on the
receiver's side that makes the final modifications in /etc. Many checks are
made to ensure reliable authorization updates. ACLs are used to enforce a
simple security policy. Differences between old and new versions are shown.
Two small scripts are included for exporting LDAP users and groups.
For a server application like a web site where
content corresponds to organizational units, NEVER use standard OS
system accounts to manage access to application data. Don't even use an
account such as OpenBSD's "staff" as an equivalent for employees. If you
examine /etc/login.conf you'll see that "staff" is a relatively privileged
group. They can login when others cannot and have higher limits on most
resources than other groups. OpenBSD's staff group is intended for computer
staff, i.e. administrators and backup operators and maybe a webmaster. It's
not an equivalent to "employees". If you need such a group, create it.
SG245962
In larger installations, good system administration usually revolves around
group definitions. Guidelines for forming groups should be part of any
security policy. Defining groups for large systems can be quite complex and is
beyond the scope of this document. Users will often belong to more than one
group, but group membership should not be excessive. One goal is to have a
moderate and stable number of groups. A symptom of poor security and poor
administrative planning is a constantly increasing number of groups.
If at all possible, group definitions should extend across all system
platforms: MVS, UNIX, NetWare, and so forth.
That is, a given group name should have the same members, the same security
associations, and similar administration on MVS and UNIX and LAN systems.
Good group definitions are often related to job functions instead of strict
organizational structures; for example, there may be a group for secretaries,
regardless of their department. This is a difficult goal. System
administrators will seldom do it voluntarily because it requires endless
coordination and meetings with other system administrators.
Nevertheless, it is a good goal because it forms and helps enforce a
meaningful security policy for an enterprise. The standard UNIX file security
controls, the permission bits, provide very limited granularity. The AIX ACL
functions extend this and are discussed in
5.6, “Access control list (ACL)”
on page 100.
Well planned use of group definitions substantially extends the usefulness
of the permission bits.
However, it must be admitted that most UNIX administrators ignore group
definitions, or, at best, define groups for use only within their system.
It can be argued that no (or minimal) group definitions are better (more
secure, less hassle) than poorly planned group definitions.
Poorly planned groups tend to overlap in unexpected (and unsecure) ways,
especially if a new group is defined for every new situation. Our
recommendations are:
- If possible, coordinate group definitions in as large a context as
possible. At the enterprise level is best.
- At whatever level the groups are defined, think! Consider scenarios. Ask
for advice.
- Once established and in use, group definitions are exceptionally
difficult to change.
The questions follow, interspersed with my summary of the replies;
I hope I have understood correctly! I have not actually pushed
at these limits yet, so cannot confirm/deny them.
> ...
> Good progress is being made with rationalising the uid/gid space
> and departments are willing and keen to conform to this.
Incidentally, several people enquired about this.
Primarily, we attempt to maintain good will with other departments,
pointing out benefits such as the automounter, if we adopt common
conventions (uid/gid, home directory structure ...).
Secondarily, but practically, we hold uid/gid information on all staff
and students in an INGRES database. We plan to allow all system
administrators to see enough of it to allow them to join users to
their own machines. The information we hold is itself gleaned from
files sent to us by the University Administration department.
> We have two (probably more!) unresolved questions about groups:
> 1. Group membership:
> a. Is there a maximum number of members to a group?
> (Counting through the "passwd" file.)
No known limit.
> b. Is there a maximum number of additional members a group may
> have? (Last field of an entry in the "group" file.)
For non-NIS, most respondents thought there was no limit, although one
thought that BUFSIZ (I assume "/usr/include/stdio.h") might be a limit.
For NIS, the "dbm(3x)" routines limit a single group entry to
just under 1024 bytes. Apparently it is possible to work around this
by creating several groups with the same GID.
> c. Do "a" and "b" interact?
No known interactions.
> d. Is there a maximum number of groups to which a user may belong?
> (SunOS pre-4.0 has a limit of 8 according to "group(5)";
> however, we are strongly encouraging our departments towards
> at least 4.0.3, preferably 4.1 or 4.1.1 .)
"/usr/include/sys/param.h" defines NGROUPS. From 4.0, this value is 16.
Some manufacturers go lower, some go higher.
BUT ... in a mixed environment using NFS, it is very unwise to exceed 8.
> 2. We follow SUN's defined groups:
> a. "staff" (group 10) is useful for installing applications
> because of directory ownership within SunOS;
> b. "operator" (group 5) is useful for disk backup (disk device
> ownership and permission) and shutdown procedures.
>
> But is all this SUN-specific? Do heterogeneous sites have
> other approaches and/or solutions?
Every vendor is different, so it seems, in defining their groups.
Generally, the solution adopted is either to live with it,
or to attempt to select the most popular machine as a local "standard"
and to (attempt to) coerce the others to fall in line.
More generally, there was a message on sun-managers on 6 Dec 1990
from "paul@concour.cs.concordia.ca"
outlining approaches to handling
large user populations.
Other sources have hinted that it may be wise to keep ordinary user
uids and gids away from the 0-1000 range. The firmness of this advice
is inversely proportional to the u/gid, so that this advice may be
meaningless in 100-999, should be noted in 50-99, and obeyed below 50.
(Having said that, we have just this week received UNIRAS 6.2a which
says it requires to use both uid and gid 21149!).
: David Lee Computer Centre :
: University of Durham :
: Phone: +44 91 374 2882 (ddi) South Road :
: Fax: +44 91 374 3741 Durham :
: ARPA:
T.D.Lee@durham.ac.uk U.K. :
: JANET: T.D.Lee@uk.ac.durham :
Claus
Färber asks:
"Is there an easy way to
add nested groups (i.e. groups that contain
or import user lists from other groups) to
Unix account management? While you can
manually add all users of one group to the
other, it is very hard not to forget to
remove or add users to all groups. I already
thought of patching NIS modules, providing a
PAM module (but will this work with Samba
and NFS?) or switching to LDAP (but RFC 2307
does not allow nested groups either...). Has
anyone already done this, or are there
better ideas?" I've always wondered
about this issue as well. Wouldn't extending
the /etc/group file to handle nested groups,
and the ability to
exclude users from
groups, be a way of implementing a more
finely grained permissions system for Unix?
To understand the advantages of nested
groups, I'll use the following example:
Typically, unix groups look like the
following:
a: user1, user2, user3
b: user3, user4, user5
c: user6, user7, user8
Now if I want to create a group "d" that
is comprised of groups "b" and "c" under
most Unices, then you'd add the following
line to /etc/groups:
d: user3, user4, user5, user6, user7, user8
Now if I were allowed to nest groups, I
could just do:
d: @b, @c
Where the "@" means 'import names from
group "b"'.
The advantage of the latter system is
that you can add users to group "b" and "c"
and not have to maintain the group "d" line
as well. Another useful extension would be
the exclusion operator, so that if I wanted
to remove a specific user from a group (to
insure said user isn't included, even if
he's a member of an included group) I could
do the following:
e: !user1, @a, @b
Instead of manually creating a new list
of individual user names:
e: user2, user3, user4, user5, user6
Now you can do something similar to this
using
NIS and netgroups for large networks,
but this feature seems to be particularly
useful for the single-machine-large-userbase
without the hassle of configuring another
service. Would you admins out there find
this to be a useful feature? If so, how
difficult would it be to modify existing
Unix systems to handle these extensions? If
not, what reasons can you give as to why
future Unix systems should not implement
this feature?
In case of broken links
please try to use Google search. If you find the page please notify
us about new location
Copyright © 1996-2008 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Last modified:
June 02, 2008
Preprocessor
(Score:4)