Managing Group Accounts in Ubuntu
Work through labs that demonstrate how to manage group accounts, including how to add, modify, and delete groups, on the Ubuntu operating system.
Save 35% off the list price* of the related book or multi-format eBook (EPUB + MOBI + PDF) with discount code ARTICLE.
* See informit.com/terms
Because Linux is a multiuser operating system, security is often based on accounts. Each person is provided a user account (see Chapter 7, “Managing User Accounts,” for details), and each user account is a member of one or more group accounts.
The group accounts are used to provide access or apply restrictions to user accounts that are members of a group. This access/restriction can be applied to files, directories, or other operating system features. By using group accounts, you can easily apply a security policy to multiple user accounts.
In this chapter, you learn more about the concept of group accounts. You also explore how to create, modify, and delete group accounts.
What Are Groups Used For?
Each person who has access to a Linux system is provided a user account. This user account offers several different features, including a user name and a password. Additionally, each user is a member of one or more group accounts.
Being a member of a group allows a user special access to system resources, such as files, directories, or processes (programs) that are running on the system. This group membership can also be used to prevent access to system resources because several security features in Linux make use of groups to impose security restrictions. These security features are covered in later chapters of this book.
Primary versus Secondary Groups
Every user is a member of at least one group. This first group is called the user’s primary group. Any additional groups a user is a member of are called the user’s secondary groups.
Group membership can be displayed by executing either the id or groups command:
student@onecoursesource:~$ id uid=1002(student) gid=1002(student) groups=1002(student),60(games),1001(ocs) student@onecoursesource:~$ groups student games ocs
The output of the id command is described in Table 6-1.
Table 6-1 Output of the id Command
Value |
Description |
uid=1002(student) |
The user ID and username for the current user |
gid=1002(student) |
The primary group ID and group name for the current user |
groups=1002(student),60(games),1001(ocs) |
The secondary group IDs and group names for the current user |
The output of the groups command includes every group the current user is a member of. The primary group is always listed first.
The most important difference between primary and secondary group membership relates to when a user creates a new file. Each file is owned by a user ID and a group ID. When a user creates a file, the user’s primary group membership is used for the group ownership of the file:
student@onecoursesource:~$ groups student games ocs student@onecoursesource:~$ touch sample.txt student@onecoursesource:~$ ls -l sample.txt -rw-rw-r-- 1 student student 0 Sep 15 11:39 sample.txt
After a file has been created, a user can change the group ownership of the file to another group by using the chgrp command:
student@onecoursesource:~$ ls -l sample.txt -rw-rw-r-- 1 student student 0 Sep 15 11:39 sample.txt student@onecoursesource:~$ chgrp games sample.txt student@onecoursesource:~$ ls -l sample.txt -rw-rw-r-- 1 student games 0 Sep 15 11:39 sample.txt
The /etc/group File
Group information is stored in several files:
The /etc/passwd file contains user account information, including the primary group membership for each user. Details regarding the contents of this file are discussed in Chapter 7. For the purpose of discussing groups in this chapter, this primary group membership is stored using the GID of the group, as shown in the following example:
student@onecoursesource:~$ grep student /etc/passwd student:x:1002:1002::/home/student:
The /etc/group file stores information about each group, including the group name, group ID (GID) and secondary user membership.
The /etc/gshadow file stores additional information for the group, including group administrators and the group password. Details regarding the contents of this file are discussed later in this chapter in the section titled “The /etc/gshadow File.”
Example 6-1 demonstrates part of a typical /etc/group file.
Example 6-1 The /etc/group File
student@onecoursesource:~$ head /etc/group root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4:syslog,bo tty:x:5: disk:x:6: lp:x:7: mail:x:8: news:x:9:
Each line in the /etc/group file describes one group. Each line is separated into fields of data, with the colon (:) character as the field separator. Table 6-2 describes these fields using the adm:x:4:syslog,bo line as an example.
Table 6-2 Fields of the /etc/group File
Field |
Description |
adm |
The group name. The group name must be unique for the current system to avoid issues related to file ownership. |
x |
The password placeholder. Group passwords used to be placed in the /etc/group file, but have been moved to the /etc/gshadow file for security purposes. This is because the /etc/group file is viewable by all users, but the /etc/gshadow file is only viewable by the root user. Details regarding group passwords are discussed later in this chapter in the section titled “The /etc/gshadow File.” |
4 |
This is a numeric value that represents the group’s ID (GID). The GID must be unique for the current system to avoid issues related to file ownership. |
syslog,bo |
This is the member list for the group. To add a user to a group as a secondary member, administrators add the user name to this field. This is typically accomplished by either the usermod or gpasswd command (see the “Adding Users to Groups” and “Group Administrators” sections later in this chapter). |
Special Groups
A typical Linux system will have many default group accounts. These default group accounts typically have GID values under 1000, making it easy for an administrator to recognize these as special accounts.
Additionally, if you add new software to the system, more groups may be added as software vendors make use of both user and group accounts to provide controlled access to files that are part of the software.
Administrators who are focused on security should be aware of these special group accounts because these accounts can provide either security features or pose security threats. Table 6-3 highlights the more important special group accounts (it is beyond the scope of this book to cover every special group).
Table 6-3 Special Group Accounts
Group |
Description |
root |
This group account is reserved for the system administrator. Do not add a regular user to this group because it will provide the regular user with elevated access to system files. |
adm |
Members of this group typically have access to files related to system monitoring (such as log files). Being able to see the contents of these files can provide more information about the system than a regular user would typically have. |
lp |
This is one of many groups (including tty, mail, and cdrom) used by the operating system to provide access to specific files. Typically regular users are not added to these groups because they are used by background processes called daemons. |
sudo |
This group is used in conjunction with the sudo command. The sudo command is discussed in detail in Chapter 7. |
staff |
A default group that was traditionally used on Unix systems but is rarely used in modern Linux distributions. |
users |
A default group that is rarely used in modern Linux distributions. |
operators |
A group that was traditionally used on Unix systems for users who required elevated privileges for specific system tasks. This group is rarely used in modern Linux distributions. |
User Private Groups
Typically when a user account is created, a group for that user is also created. This is designed to overcome a scenario that was common in the early days of Linux where system administrators would routinely add all users to one group (typically called “users” or “staff”).
This practice resulted in a situation where users were provided access to files that they shouldn’t have access to. By placing everyone in a single group, every new file that every user created was owned by that group, which meant that either everyone in the organization had access to the file via the group permissions or the user had to remember to remove all permissions for the group for each new file created. Figure 6-1 demonstrates the problems that this scenario creates (file1.txt demonstrates the security risk, and file2.txt demonstrates when a user remembers to remove all permissions for the group).
Figure 6-1 The Issue with Having a Global Group for Everyone
The concept of creating a group for each user is called User Private Groups (UPGs), where each user has their own group as their private group, meaning the security risk of all users being able to access the files of all other users is limited.
Unfortunately, this approach also poses security risks if the system administrator doesn’t handle group membership correctly. UPG essentially makes the user’s primary group worthless (at least by default) because the user is the only member of this private group. If the user isn’t a member of additional groups, then to give access to a file for a specific user, the others permission set is often used. This ends up giving access to everyone on the system, which is the very problem that UPG was designed to avoid. Figure 6-2 demonstrates the problems that this scenario creates.
Figure 6-2 Potential Issue with UPG
UPG does provide a solution, but only a partial one. The administrator must also implement a security policy to include one or more of the following:
A procedure to place users into additional groups to make it easier for people who work together to share access to files.
A plan to teach proper use of permissions to all users. A detailed discussion of this topic can be found in Chapter 9, “File Permissions.”
The administrator should consider allowing users the ability to add new users to their own private group. A detailed discussion of this topic is provided in the next section, “The /etc/gshadow File.”
A plan to teach users how to use access control lists (ACLs), a method of assigning permissions to specific users or groups. A detailed discussion of this topic can be found in Chapter 9.
The /etc/gshadow File
The /etc/group file contains some of the group account information, but more can be found in the /etc/gshadow file. This file is only viewable by the root user, so more sensitive data is stored in the /etc/gshadow file.
Example 6-2 demonstrates part of a typical /etc/gshadow file.
Example 6-2 The /etc/gshadow File
root@onecoursesource:~# head /etc/gshadow root:*:: daemon:*:: bin:*:: sys:*:: adm:*:student:syslog,bo,student tty:*:: disk:*:: lp:*:: mail:*:: news:*::
Each line in the /etc/gshadow file describes one group. Each line is separated into fields of data, with the colon (:) character as the field separator. Table 6-4 describes these fields using the adm:*:student:syslog,bo,student line as an example.
Table 6-4 Fields of the /etc/gshadow File
Field |
Description |
adm |
The group name. This matches up with the group name in the /etc/group file. |
* |
The group password. A value of * or ! means “no valid password set.” This password is used with the newgrp command and set by the gpasswd command. See more about this password in the discussion following this table. |
student |
The group administrator for the group. Group administrators can add and remove users from the group. See the section titled “Group Administrators,” later in this chapter. |
syslog,bo,student |
This is the member list for the group. This should match up with the corresponding field in the /etc/group file. |
The purpose of the password field in the /etc/gshadow file is to allow users to temporarily change their primary group by using the newgrp command. By default, any user who is a member of a group can switch their primary group:
student@onecoursesource:~$ groups student adm games ocs student@onecoursesource:~$ newgrp games student@onecoursesource:~$ groups games adm ocs student
Users cannot switch their primary group membership to a group they don’t belong to, unless they know the password for that group. This password is set by the administrator using the gpasswd command:
root@onecoursesource:~# gpasswd staff Changing the password for group staff New Password: Re-enter new password: root@onecoursesource:~# grep staff /etc/gshadow staff:$6$iv.gICgaA$iWGw611b/ZqKhu4WnMfA9qpNQvAQcljBFGuB1iXdWBhMWqgr2yQn7hn6Nu8BTrtErn734 wLDhWzS6tNtJmkV/::
Once the password has been set, a user can change their primary group by entering the group password at the prompt when running the newgrp command:
student@onecoursesource:~$ groups student adm games ocs student@onecoursesource:~$ newgrp staff Password: student@onecoursesource:~$ groups staff adm games ocs student
Although you can use the group password method, consider this: If you want to allow a user to switch to a new primary group, why not just add them to that group? Because of this logic, group passwords are not very often used on Linux systems.
See Figure 6-3 for additional information.
Figure 6-3 Text Support™—Changing Primary Groups