Linux with Operating System Concepts

Option
Meaning
-c
Maximum core file size, in blocks
-e
Scheduling priority for new processes
-f
Maximum size of any newly created file, in blocks
-m
Maximum memory size useable by a new process, in kilobytes
-p
Maximum depth of a pipe (pipe size)
-r
Real-time priority for new processes
-T
Maximum number of threads that can be run at one time
-v
Maximum amount of virtual memory usage, in kilobytes
-x
Maximum number of file locks (number of open files 
allowable for the shell)

---

378
◾
Linux with Operating System Concepts
As an example of establishing access to a system administration program, let us consider 
the groupadd instruction. The groupadd instruction has permissions of 
rwxr-x--- 
so 
that it is not accessible by the world. The user and group owner of groupadd are both root. 
Therefore, root is the only user that has access. However, groupadd is a relatively harmless 
instruction. That is, it will not interfere with user accounts or existing groups. So, we might 
allow users to use this instruction.
The process is twofold. First, the system administrator must edit the /etc/sudoers file. 
Entries in this file have the format:
username(s)
host
=
command
Username
is the username of the user who we will allow access to sudo. If you are not 
listed under the username, any attempt to use 
command
via sudo will result in an error 
message and the event being logged. To specify multiple users, list their usernames sepa-
rated by commas but with no spaces. Alternatively, you could specify 
%users
to indicate 
all users of the system, or some other group using 
%groupname
.
The value for host indicates for which machine this sudo command is permitted. You can 
use ALL to indicate that this sudo command is valid on all computers for a networked system 
or localhost for this computer. Alternatively, you could use this computer’s HOSTNAME.
Finally, the command(s) should include full paths and options and parameters as needed. 
If you have multiple commands, separate them by spaces. Our entry for groupadd could be
%users localhost
=
/usr/sbin/groupadd
Once edited, you save the sudoers file.
The second step is for a user to issue the command. The command is simply the com-
mand preceded by sudo, as in 
sudo groupadd my_new_group
. The sudo program 
will require that the user submit his or her password to ensure that this user is authorized 
to execute the command. This password is timestamped so that future usage of sudo will 
not require the password. We see later that the timestamp can be reset.
Now that users can create their own groups, can they start populating those groups 
with users? The groupadd command does not allow us to insert users into a group. For 
that, we would need to provide access to usermod. We would want to only provide access 
to 
usermod -G
.
So, now we modify the sudoers file again. Our entry in the sudoers file could be
%users localhost
=
/usr/sbin/usermod –G
A user can now issue the command
sudo /usr/sbin/usermod –G 
group1
,
group2 newuser
to add 
newuser
to 
group1
and 
group2
. As the sudoers file specifies that usermod includes 
the -G option, a user would not be able to issue a usermod command with other options.

---

User Accounts
◾
379
We do not really want to provide sudo access to either of these two commands because 
they constitute a security breach. Imagine that we let zappaf use both of these instructions. 
The user zappaf could create a new group, hackers, using the command.
sudo /usr/sbin/groupadd –g 0 –o hackers
followed by
sudo /usr/sbin/usermod –G hackers zappaf
What has zappaf done? He has created a new group that shares the same GID as root 
and then added himself to this group, so zappaf is in a group shared with root. With such 
a privilege, it is possible that zappaf could exploit this to damage the system.
What follows are some examples that we might want to use sudo for. The first example 
allows users to view some directory that is normally inaccessible. The second example per-
mits users to shut down and reboot the computer from the GUI. The third example allows 
users to mount the CD. There would be a similar capability for unmounting the CD.
• 
sudo ls /usr/local/protected
• 
sudo shutdown -r +15 "quick reboot"
• 
sudo /sbin/mount/cdrom
You might find other sudo options useful depending on circumstances. The -b option 
runs the command in the background. This could also be accomplished by appending & 
to the instruction. With -H, sudo uses the current user’s HOME environment variable 
rather than the program’s user. From earlier, if dukeg ran zappaf’s executable program 
without -H, HOME stores /home/zappaf while with -H, HOME stores /home/dukeg. This 
could be useful if the program were to utilize or store files for the given user rather than 
the owner.
In addition to the described options, the option -K is used without a command (i.e., 
sudo –K
). The result of -K is that the user’s timestamp reverts to the epoch. In essence, 
this wipes out the fact that the user had successfully run sudo on this command in the 
past and will now require that the user enter their password the next time they use sudo. 
Similarly, the -k option will reset the user’s timestamp. The -k option, unlike -K, can be 
used without or with a command.
The 
visudo
program should be used to open and edit the /etc/sudoers file whenever 
you, as a system administrator, want to modify /etc/sudoers. visudo opens /etc/sudoers in 
vi but there is a difference between using visudo and opening the file yourself in vi, which 
is that visudo will check the file for syntax errors before closing the file. This will inform 
you of potential errors so that you can fix them at the time you are editing the file rather 
than waiting to find out there are errors when users attempt to use sudo at a later point 
in time.

---

380
◾
Linux with Operating System Concepts
9.8 ESTABLISHING USER AND GROUP POLICIES
To wrap up this chapter, we briefly consider user account policies. These policies might 
be generated by the system administrator, or by management, or both. Once developed, it 
will be up to the system administrator to implement the policies. Policies will impact who 
gets accounts, what access rights they have, whether they can access their accounts from 
off-site, or whether they can use on-site computers to access off-site material (e.g., personal 
email), and how long the accounts remain active, to name a few.
9.8.1 We Should Ask Some Questions before Generating Policies
We have to ask: what is the nature of our users?
• Will we have different levels (types) of users?
• Will users have different types of software that they will need to access and different 
files that go along with them?
• Will different levels of users require different resources, for instance, different 
amounts of hard disk space, web server space, and different processing needs?
The answers to these questions help inform us how to handle the users. If we have differ-
ent levels of users, then we might have different types of accounts. A university might, for 
instance, provide different disk quotas and resource access to administrators, staff, faculty, 
and students. In an organization that clearly delineates duties to different software, we 
might want to establish software accounts so that only certain users have access. We might 
need to limit Oracle database client software because of a site license so that only those 
users who require access will be given an account whose role matches the files that they 
would need to access.
We have to look at our resources and ask whether we have enough resources so that 
restrictions are not necessary.
• Will we need to enforce disk quotas? If so, on all partitions or on specific partitions? 
Can different users have different quota limits? (See Chapter 10 for a discussion on 
disk quotas.)
• Will we need to establish priority levels for user processes?
• Will users have sole access to their workstations; will workstations be networked so 
that users could potentially log into other workstations; will resources be sharable?
If users have sole access to their workstation, it sounds like this would simplify the task 
of the system administrator. However, if network resources are being made available, the 
system administrator would still need to maintain networks accounts. Additionally, giving 
users sole access to their workstation could potentially lead the users to take actions that 
might harm the workstation. Giving the user the ability to download software onto their 
workstation could open up the workstation to attack by viruses, Trojan horses, and spyware.

---

User Accounts
◾
381
We also want to ask questions about the accounts themselves.
• Will accounts exist for a limited amount of time or be unlimited? For instance, in a 
university setting, do we delete student accounts once the student graduates? If so, 
how long after graduation will we eliminate them? For a company, how long should 
an account remain in existence after the employee has left the company?
• What password policy will we enact? No organization should ever use anything other 
than strong passwords. How often should passwords be changed? Can passwords be 
changed to something similar to previous passwords?
The policies that we establish will be in part based on the type and size of the organi-
zation. Larger organizations will have more resources, but also greater demand on those 
resources. Smaller organizations may not be able to afford the more costly file servers and 
so may have greater restrictions on file space usage.
Policies will also be driven by management through some form of risk assessment and 
management. Risk assessment and management are based on the identification of orga-
nization assets and those assets’ vulnerabilities and threats. Assets are not limited to the 
physical hardware such as the computers, file servers, and printers.
Probably even more critical as assets are the data owned by the organization. A com-
pany with clients would not want the client data to be accessible from outside. Any such 
access would constitute a breach in the privacy of the individuals’ data that the organiza-
tion has retained. Some of this data would be confidential, such as credit card numbers, 
and thus a breach in privacy would impact not only the clients but also their trust in the 
organization.
Protection of confidential and sensitive data might provide us with the most important 
of our policies. We might, for instance, limit access to the data to a select group of employ-
ees. We would require that these employees log in to the database system before access. 
We would require that the passwords be strong and we would enforce timely password 
changes. We might also require that database passwords differ from the passwords used to 
log into their computers.
Other policies might be less critical from a security perspective but equally important 
for management. For instance, should employees be allowed to use work email for personal 
business? If so, this could result in a security hole and a use of organizational resources that 
seems wasteful. On the other hand, employees may resent not being able to send personal 
emails from work. Should we limit website access? We might, through a proxy server or 
firewall, prohibit access to such websites as those of Facebook, Twitter, and even ESPN. 
Finally, should system administrators have the rights to (or responsibility to) examine 
users’ file spaces such as to see if users are using email for personal use or to examine web 
browser caches for inappropriate website access?
9.8.2 Four Categories of Computer Usage Policies
Below, we break policy issues into four categories: user accounts, passwords, disk space, 
and miscellany. For each of these, we discuss possible options.

---

382
◾
Linux with Operating System Concepts
For user accounts, the questions are
• Does every user get an account? This would be the most likely case.
• Should users share accounts? This can be a security violation and is generally not 
encouraged.
• How long do user accounts remain active after the user is no longer with the orga-
nization? Companies may disable such accounts immediately. Other organizations 
might wait a few weeks. Universities often keep student accounts active for some time 
after graduation, possibly even permanently (or alternatively, the accounts remain 
active but are shifted to other servers). If accounts are disabled or deleted, do the users 
get some notification? What happens to any files owned by deleted accounts?
• What resources come with an account? File space? Web server space? Remote access? 
Access to one workstation or all workstations? Access to one printer, multiple print-
ers, or all printers?
Password policies revolve around what sort of password management the organization 
wants to enforce
• Will users be given an initial password?
• Will the organization enforce strong passwords?
• How often will passwords require changing?
• Can passwords be reused? If so, at what frequency? If not, can password variations 
be permitted?
Disk space utilization policies concern quotas and types of file space access:
• Will files be placed locally or on a file server? If the latter, is file sharing allowed?
• Will users have disk quotas?
• Should files be encrypted?
• Does file space also exist for the web server?
• Are the users allowed to store anything in their file space?
• Are there policies giving system administrators permission to search user file space 
for files that should not be there (e.g., illegal downloads)?
Miscellaneous topics include how to implement and enforce protection and security, 
backups and disaster planning, and replacement of resources. As most of these issues are 
not related to users and accounts, we will hold off on discussing these until later in the 
textbook.

---

User Accounts
◾
383
9.9 CHAPTER REVIEW
Concepts introduced in this chapter:
• Epoch—the date January 1, 1970, used in some Linux commands and files to count 
the number of dates until an action should take place (e.g., modifying a password).
• GID—the ID number assigned to a group. This is an integer used for bookkeeping.
• Group—an account generated to permit a third level of access rights so that resource 
access can be established for a specific collection of users. In Linux, each user account 
is typically accompanied by a private group populated by only one user.
• PAM—pluggable authentication module allows a system administrator to tailor how a 
program or service will achieve authentication by calling upon any number of modules.
• Password—a means of implementing access control by pairing a username with a 
password known only to that user. Passwords, for security purposes, are stored in an 
encrypted manner.
• Private group—a group account generated for most user accounts whose name matches 
that of the user. The private group should contain only a single user, that of the owner. 
Files and directories created by a user default to being owned by this private group.
• Strong password—a set of restrictions placed on passwords to make them hard to 
crack. Typically, a strong password should combine letters with at least one nonal-
phabetic character, be at least eight characters long, and be changed no less often than 
every three months.
• UID—the ID number assigned to a user. This is an integer used for bookkeeping.
• User—a person who uses the computer to run processes.
• User account—the account generated so that users can log into the computer and so 
the operating system can differentiate access to resources. In Linux, there are three 
types of accounts: root, normal users, and software.
• User Manager—the Linux GUI application used to create, modify, and delete user 
and group accounts. See also the Linux commands groupadd, groupdel, groupmod, 
useradd, userdel, and usermod.
• User policies—usage policies established by management in conjunction with the 
system administrator(s) and implemented by the system administrator to dictate 
such aspects of user capabilities such as software access, download capabilities, file 
space quotas, website and email usage, and password management.
Linux commands covered in this chapter:
• apg—third-party software package to automatically generate random passwords.

---

384
◾
Linux with Operating System Concepts
• chage—control password expiration information.
• groupadd—create new group.
• groupdel—delete existing group.
• groupmod—modify existing group (use usermod to add users to a group).
• newusers—program to generate new user accounts given a text file of user data. This 
is an alternative to developing your own script as we did in this chapter.
• pam—password authentication module to handle authentication responsibilities for 
most or all applications that require user authentication.
• passwd—used to modify user passwords but can also be used to control password 
expiration information similar to chage.
• sudo—allows a user to execute a program as another user. Most commonly used so 
that the system administrator can give access to some root programs to other users.
• tr—used to translate characters from one format to another. When coupled with 
/dev/urandom, we can take the randomly generated characters and convert them into 
readable ASCII characters to generate random passwords.
• ulimit—used to establish limits on resources in the shell session.
• umask—used to set default permissions when new files and directories are created.
• useradd—create a new user.
• userdel—delete an existing user.
• usermod—modify attributes of an existing user.
• visudo—open the /etc/sudoers file in vi for editing and syntax checking.
Linux files covered in this chapter:
• .bash_profile—script file placed in user home directories, executed whenever a user 
opens a new Bash session. Users can modify this file to add environment variables, 
aliases, and script code.
• .bashrc—script file placed in user home directories, executed by .bash_profile. Users 
can modify this file to add environment variables, aliases, and script code.
• /dev/urandom—software serving as a device that provides random number genera-
tion. Can be used to generate random passwords.
• /etc/bashrc—script file executed whenever a user starts a new Bash session. Controlled 
by the system administrator.
• /etc/group—file storing all of the groups defined for the system and the groups’ mem-
bers. This file is readable by the world.

---

User Accounts
◾
385
• /etc/login.defs—default values used by a number of different programs such as 
useradd.
• /etc/pam.d—directory of configuration files used by PAM.
• /etc/passwd—file storing all user account information. This file does not include pass-
words (as the name implies). The file is readable by the world, so any user can view 
account information about users (e.g., user’s username, home directory, login shell, 
UID, full name).
• /etc/profile—script file executed whenever a user logs into the system. Controlled by 
the system administrator.
• /etc/shadow—file storing password information for all users and groups. All pass-
words are encrypted. Other information such as password expirations are listed here. 
This file is accessible only by root.
• /etc/skel—directory controlled by the system administrator containing initial files 
and directories to duplicate when a new user is added to the system. Anything stored 
here is copied into the new user’s home directory upon user account creation.
• /etc/sudoers—file storing sudo access rights. See the sudo instruction. This file should 
only be opened using visudo.
REVIEW QUESTIONS
Note
: In questions dealing with usernames, assume usernames will be of the form last-
name followed by first initial like foxr, zappaf, or dukeg.
1. Of the various items to enter when adding a new user using the GUI (see Figure 9.2), 
which fields are required and which are not? Which can you leave unmodified?
2. Using the GUI (see Figure 9.1), how would you delete a user? A group?
3. Using the GUI (see Figures 9.1 and 9.2), how would you add a user using all of the 
defaults except that the user would have a home directory of /home/faculty/