This lesson discusses two chapters in our text on Linux. Objectives
important to this lesson:
inetd and xinetd
The shadow password suite
Regular and special permissions
Pluggable authentication modules
Chapter 3, Starting Off
Chapter 3 has a lot of basic material that leads to more complex ideas.
It starts with a warm up about distributions:
are three versions of the same thing. The author is a little off: RHEL
is a stable version of Red Hat that come with support, Fedora is a developmental
version that has no support, and CentOS is a lighter version of Red
Hat that also has no support.
Debian is a
good stable version of Linux, and other versions are based on it.
Ubuntu is based
on Debian. It is supported by a company, Canonical, Ltd.
Mint is based
on Debian and Ubuntu. It is not supported by a company. The text tells
us it is supported by users, and that it has two available GUIs. Actually,
there are three: Cinnamon,
Mate, and Xfce.
The text mentions two distributions that are "for power users",
Arch and Gentoo.
They are more for users who want to build their own customized systems
than for users who need a system that can be updated, trusted, and used
to run a business.
The chapter moves on to consider installing your choice of Linux on a
regular computer, as you would any operating system, on a virtual
computer, or on a virtual computer provided by a cloud vendor.
These choices exist for any operating system, not just Linux. The
discussions that follow would be the same regardless of your OS choice.
The text moves from the discussion of a regular hardware install
to discussing general security issues that relate to the hardware
being accessed by a hacker. It is more likely that this will happen
if you own a laptop that is stolen by a hacker, but it can happen to
a non-laptop computer as well. The author recommends a strong password
for the operating system, and another for the BIOS where you
can make settings to prevent booting from a hacker's disc or memory
stick. The discussion does not deal with the typical user reaction to
an extra password, which is to curse loudly and to write it on an easily
The discussion of virtual machines begins with a page of history
about the concept itself. It reviews the basic concepts, such as needing
an application that allows the virtual device to run in managed
RAM. The security issues the text brings up are a hacker not only taking
control of a virtual machine, but escaping the virtual
and taking control of the management interface, the hypervisor,
which would grant the hacker control of any other virtual devices running
on the same system. As an incentive for running virtuals, the text mentions
that the management software can typically take a safety copy of the
current machine (a snapshot) before you install an update that
may not work. The virtual device can roll back to the copy in the snapshot,
avoiding having to undo the installation of the new patch/feature/application
that became a problem.
Remember that "the cloud" just means that we are
reaching across a network (usually the Internet) to use someone else's
computer. Running a virtual computer on a computer in the cloud means
that you don't have to buy hardware (that you don't already own) that
would support an OS you want to run.
The text turns to a choice of boot loader. It describes two, the Linux
Loader (LILO) and the Grand Unified Boot loader (GRUB).
The bottom line is that GRUB supports more systems and has more features.
The text mentions that neither of these support GPT disks. The
reason you would want to use hard drives that support GPT is explained
in this document
from Microsoft: they support disks larger than 2 terabytes. We
are told to use GRUB2, the improved version of GRUB, if we want
to use GPT disks in our computers.
The author spends about five pages listing the names of services and
scripts that can run services in his example operating system. On page
65, he shows us syntax for the service command which can start
and stop services. This example is from an article
sudo service httpd
sudo service httpd
sudo service httpd
Each of these commands begins with sudo, which invokes elevated
rights. The actual command name, service,
follows, which is followed by the name of a service. In this case, the
service name is httpd, the daemon
for the http service. The commands end with the action to take:
start, stop, or restart. Depending on the shell
you are running, a command may also have to end with a semicolon to be
text discusses inetd, which it describes as a super
server, but it does not explain that term very well. It means
that it is a server (service) that starts other servers (services). In
this case, it means that inetd starts other daemons.
(The image on the left is one of many that combine the the concept of
demon and penguin, which means Linux daemon.) The inetd daemon runs all
the time and calls other daemons when they are needed. One idea behind
this practice is to keep daemons out of memory until they are needed.
Another is to limit who can get access to the called daemons.
The text explains there is a problem with inetd. It does not provide
adequate restrictions on the called services. An improved version of inetd
is xinetd (making it an X-men daemon?) This daemon allows the use
of configuration files that specify settings on the daemons to be called,
restricting them with whitelists (allowed addresses and systems) and blacklists
(disallowed addresses and systems). The key for a whitelist is allow_from.
The key for a blacklist is no_access.
The last topic in the chapter is r-services, which are remote
services on networks running UNIX, Unix, or Linux. They differ from regular
services in that they are run on a remote system through either inetd
or xinetd. The super-server daemon opens a connection to the remote server
and determines whether the command the user wants to run can be run. The
text warns us that this kind of service does not feature strong authentication,
making it subject to exploitation.
Chapter 4, Privileges and Permissions
Chapter 4 begins with a feature in Linux that is a little hard to understand.
We are told that user names and passwords used to be stored in
the same, clear text file (i.e. /etc/passwd). The improved versions of
Linux have two newer files: /etc/shadow contains encrypted passwords
for users, and /etc/gshadow contains encrypted passwords
for groups. It may be easier to think about four files in this
- This file contains seven fields of information about each user
account, separated by colons:
username - The user's login name
password - This field contains an encrypted password, an
x, or an asterisk. x means the password is
in the /etc/shadow file; * means the account is disabled
user ID - A number for the user account
group ID - A number for the user's main group
user information - other user information or nothing; in
practice, this field may contain the display name of the
home directory - The directory this account is set to upon
login. The entry here included the path to the user's home
login shell - The path to the shell that starts for the
user account upon login
- This file contains four fields of information about each group
groupname - The name of the group; the text mentions that
users typically belong to a group whose name matches their username
password - The expected value is x, which means the password
for the group is in the /etc/gshadow file (The text is wrong
about this on page 77.)
group ID - A number for the group; numbers here match the
ones in the group ID fields in user lines in /etc/passwd
group members - users who are members of this group
- This text says the file holds eight fields of information about
user accounts, separated by colons. The link to Red Hat documentation
says nine fields.
username - Login name of the account this line is about
password - An encrypted version of the user's password,
typically a salted MD5 hash
date password was last changed - The date the password
was last changed, expressed as the integer of the number of days
since 1/1/1970. This reference date is called the epoch.
(Someone was rather dramatic, weren't they?) The epoch date for
10/27/2018 (American format), for example, is 17831. (The star date
for that date is 43400. Trust me...)
minimum password life - The number of days that must pass
between password changes.
maximum password life - The number of days a password may
be used before it expires.
password warning period - The number of days before password
expiration in which the user will be warned of the pending expiration.
inactive period - If the password expires, this is the
number of days that must pass without a login before the account
is automatically disabled.
disabled period - If the account is disabled, the number
of days it has been disabled.
reserved field - Red Hat documentation says there is another field
here that it ignores.
- This file holds four fields of information about group accounts:
group name - Name of the group.
Password - An null, an encrypted password, an exclamation
point, or a double exclamation point. A null means only
members can log in to the group. If a user knows this password,
they can join the group by using it and the group name with the
with the newgrp command. If this field contains an exclamation
point, users are not allowed to join the group with the newgrp
command. Two exclamation points mean the same, and also mean
no password has ever been set.
administrators - Members named in this field can add and remove
members - Regular members of the group.
The shadow and gshadow files are readable only by the root user and by
processes that need information from those files.
On page 80, the text lists nine security directives that are contained
/etc/login.defs file. These are default settings and behaviors
that affect users:
FAILLOG.ENAB - /var/log/faillog is set as the default file for failed
LOG_OK_LOGINS - /etc/syslog.conf is set as the default file for successful
SYSLOG_SU_ENAB - enables logging of the use of the su command (used
to switch users for the current session, or to impersonate root for
SYSLOG_SG_ENAB - enables logging of the use of the sg command (used
to execute a command as a member of a different group)
FTMP_FILE - enables failed login attempts to be logged in a named
PASS_MAX_DAYS - maximum lifespan of a password
PASS_MIN_DAYS - minimum age at which a password may be changed
PASS_MIN_LENGTH - mimimum length of a password
LOGIN_TIMEOUT - maximum time to accomplish a login (in seconds)
Page 81 presents a list of commands related to managing users. Most are
intuitve, since they are only words "user" and "group"
combined with the syllables "add", "mod", and "del".
The only one I would consider nonintuitive is chage,
which is used to change the age of a user's password, but
it does more than that. Take a trip to the web page behind the link in
the last sentence. You will see several examples that show some of the
other uses of this command. It should be obvious that it can override
the settings in the login.defs file.
As you may expect, you can manage user permissions through membership
in groups. The text discusses this for a few pages in the context
of using the user and group commands. You should try out the commands
on pages 84 and 85 about setting up a special group. To do this, you probably
want to create a Linux implementation in a virtual device. In case you
have never done this, run through the following video which does a good
job explaining the downloads you need, installing VirtualBox, and using
a downloaded .iso file to install the version of Linux you want to use.
As mentioned in the notes above, the su command is used to switch to
a different user account, and the sg command is used to switch to a different
group's rights. Page 86 discusses the use of each command. Note the use
of the su command with the -c switch, which is shorthand for "use
the administrator account for the command that follows on this line".
You would be prompted for the root password if you issued such a command,
but it is worth knowing that it can be done once you know the password.
The end of the chapter has a few observations that apply to the various
discussions in it. Here are some we should consider:
Protect the shadow suite files.
Understand the use of the su, sg, and sudo commands to gain root privileges
for a command.
Note the use of the /etc/sudoers file that controls who can use the
sudo command and within what limitations. This
article about that file from TecMint provides ten observations
about limiting the sudo command's use. It includes links to related
articles as well.
The text also calls our attention to logs in the /var/log/ directory.
This article presents a more useful list of the logs you
will find there, and their contents. You should try out the log viewer
it discusses, but note that it may not be available on servers.
Assignments for this chapter will be found in Canvas. We will explore
that in class.