Unix Groups administration

News	Recommended Links	Rainbow Books	Authentication	Unix permissions model	Solaris RBAC	History
Wheel Group		Admin Horror Stories	Unix History	Humor	Humor	Etc

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.

Old News ;-)

[May 6, 2008] freshmeat.net Project details for Silk Tree by Aleksandr O. Levchuk

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.

GeodSoft How-To Hardening Systems, Users, Groups and Security

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.

1991 Summary UNIX groups

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 :

Slashdot Nested Groups on Unix

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?

Corporate solution
(Score:2)
by CoderDevo (30602) <coderdevo@hotmail.com> on Wednesday December 13 2000, @03:59PM (#563660)
(http://slashdot.org/)
If the nested groups under Unix problem needs to be solved for all systems in a corporation, then let me suggest Conrol-SA from BMC Software. It provides one GUI console to manage users and groups for all systems in the enterprise.

Control-SA uses an entity called a Job Code to associate the groups a user needs to be a member of to perform his/her job. These groups can even be on different systems. When a new employee joins the company, you drag and drop the Job Code onto the User. All user accounts for that person are created on all systems they need access to based on the groups to which the Job Code is connected.

In fact, Control-SA even catches and displays changes to user accounts if a system administrator modifies the accounts without using the Control-SA GUI.

I'm sorry for the plug, but I spend all of my time working with this stuff and I love it.
Preprocessor
(Score:4)
by alannon (54117) on Tuesday December 12 2000, @06:30PM (#563665)
Maybe I'm being a little bit naive, but wouldn't it be possible to simply write a preprocessor that followed your rules and spat out a completed /etc/groups file as a result? Then your solution would be portable and would require no new additions to any other systems.