Users, Groups and Security

• Shared Write Access to a Directory

This page provides an overview of the use of groups in the management of computer security. Why groups and not individuals should have privileges is explained. It's generally applicable to most systems but some UNIX specific techniques are covered.

For machines that don't require content management, such as firewalls and servers like mail and DNS (or where the content requires technical level expertise if you regard routing tables as content) there may only be one or two administrators with access to the machine. FTP servers may have content management issues requiring more than one level of management and web servers may have several levels of users. In addition to system administrators, a web server is likely to have a web master, technical staff such as programmers and database administrators and less technical web page authors. Different functions may overlap so that one staff person performs more than one role.

The best way to deal with differing functions is to create groups that are assigned to the function and give the groups the necessary read, execute or update permissions in the directories related to their functions. In large organizations, job positions are clearly defined and there are typically distinct functions occupied by multiple and changing staff. The appropriate groups are often easy to define as they tend to go with specific job titles or levels within organizational units.

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.

As organizations get smaller, functions may go with individuals across title changes and even organizational unit changes. Even so it's easier to match functions to groups, give access to the group and move the individuals between groups as necessary. This is true even when individuals need to be in multiple groups and different individuals have different combinations of groups. What changes as organizations get smaller is not the group concept but that there are less groups with broader scope.

If access rights go with groups, assuming the function was being successfully performed, the groups have at least the minimum permissions necessary to perform the function. The most that needs to be changed when there are staff or job position changes is to move one or two individuals in or out of at most a few groups whose function should be clearly described by the groups name.

If permissions go with individuals, then each time there is an organizational change, an analysis needs to be performed to determine what access rights are specific to the changes. If an individual is being replaced this may be fairly straight forward but if persons are moving within the organization it could be a major task to distinguish what an individual accesses as an individual and what in specific functional roles. If an individual has more than one function, what access goes with each function needs to be determined. Even the simplest replacement may require changing individual access rights in several scattered directories. If both the analysis and implementation are not done correctly someone may not be able to perform a required function after changes are made. On UNIX systems, two individuals can't share the same access unless it is via a group, as files have only one individual and one group owner.

The worst approach is to eliminate security obstacles to the performance of any functions by giving full access to everything to everyone. Next worst is to create shared logons that go with functions. This provides no accountability as there is no way to know what individual actually performed shared logon actions. It is also likely to lack the necessary flexibility. To be even workable there will be too few accounts with overly broad permissions or many specific accounts causing users to log on and off to perform different functions.

When a new function is developed that is performed by only one individual it can be hard to avoid the temptation just to give that individual the necessary access. The benefits of taking the extra time to create a new group, put one user in the group and give the group access to new resources that go with the function, may not be apparent but in the long run it will be more efficient.

Shared Write Access to a Directory

When a UNIX system has a group, such as web page authors, who need to collaborate, there are some steps that can be taken to assure that all members of the group have write access to files that need to be fully shared. By default, the group owner of a file is the creator's primary group. Since different individuals are likely to have different group combinations, it may not be practical or even possible for all members of a group that needs to share files, have the same primary group. On OpenBSD and some Linuxes a new group is created for each new user that matches the user's name and is the user's primary group. On these systems, different individuals cannot share primary groups.

If a directory GUID bit is set, then files created in that directory will have the group owner of the directory which may be different than the creator's primary group. For a collaborative directory, "chmod 2775 dirname" will set the directory GUID bit and make the directory, owner and group writable and world readable. If the read and write permissions are otherwise correct, "chmod g+s dirname" will make the directory GUID.

By setting the user's umask to 002 rather than the more standard 022, files they create will be group writable. If the user's primary group is a unique group that matches their user ID, then umasks of 022 and 002 are functionally identical, except in directories that are GUID. In these directories newly created files will be owner and group writable and world readable. In other directories, the files will still be group writable but since there are no other members of the group, they will effectively be only owner writable and group and world readable.

To create a web document tree in which all documents created in the tree will be writable by members of a specific group do the following. Create an new group such as webauth that is to have write privileges in the web document tree. Make the entire document tree group owned by webauth ("chgrp -R webauth document_root") and set the document tree permissions to look like drwxrwsr-x ("chmod -R 2775 document_root"). If the document tree already contains files use find to selectively set file and directory permissions and avoid setting all files as executable:

find . -type -d -exec chmod -R 2775 {} \;
find . -type -f -exec chmod -R 664 {} \;

Add all web authors to the group webauth and give them a umask of 002 (at least while they work on web documents, if not all the time). If one does not already exist, create a unique group that matches each web author's user name and make this the primary group for each web author. The directory owner is not particularly important.

If the web site is larger and there are groups such as hr, research and sales, the same approach will work in subdirectories specific to each group. A webmaster or anyone else who needs write rights in all these directories would be a member of all the groups.

Sometimes there will be a need to create shared directories that unlike a web site should be semi private and not world readable. The same approach as described above for websites is applicable, except that the directory or directories should not be world readable. An example would be a directory where a department shared documents private to the department such as finance or HR. In these cases the chmod masks would be 2770 for directories and 660 for files.

There is another technique related to groups generally applicable to UNIX systems. This is to protect su so that only members of a specific group can use it. Typically this group is wheel but security is the appropriate group on AIX. su is normally delivered world executable. It requires that the SUID bit be set and the file be owned by root to work. With the standard settings on most systems, any user who obtains the root password can su and effectively become root. OpenBSD proactively fixes the problem by modifying su so that it checks what groups the person running it belongs to and if they are not in wheel and wheel has members, su exits with an error message; no permission setting changes are required.

On other systems the group owner of su should be changed to wheel, or root on some systems, or security on AIX. Members of this group should be restricted to those who are given and authorized to use the root password. Su is left group executable but world execution rights are removed. This prevents anyone who is not authorized to use the root password, from using it under most circumstances, even if they learn the root password. Most server consoles are in secure areas where non technical staff do not have access or are very conspicuous. On systems that do not allow direct root access from remote locations, it not only takes two passwords to gain root privileges but they have to be the right two passwords. The first password is reduced from the entire user population to a very small population that hopefully pick good passwords.

The technique might be extended to other programs though none have quite the security implications of su. I would never set the SUID bit on a program that did not have it and then restrict the use of that program to wheel. Rather the members of wheel should su or sudo to access the program. Where the technique may make sense is if there are programs that are already SUID and it is believed that the functions provided by these programs are not needed by ordinary users. Presumably the system authors thought world execute access is not particularly harmful or the program would not be set up in such a way. Removing world access and changing the group owner to wheel restricts access to the program while keeping it convenient for wheel members. To make such programs secure, the SUID bit should be reset, forcing wheel members to su or sudo to use the command.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.