ITS 3250 - Securing Systems

Security Strategies in Linux...
Chapters 3 and 4

This lesson discusses two chapters in our text on Linux. Objectives important to this lesson:

  1. Distributions
  2. Delivery platforms
  3. Boot loader
  4. Services
  5. inetd and xinetd
  6. r-services

  7. The shadow password suite
  8. User privileges
  9. Groups
  10. Admin privileges
  11. Regular and special permissions
  12. Tracking access
  13. Pluggable authentication modules
  14. polkit
  15. Network authentication

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:

  • RHEL, Fedora, and CentOS 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 accessed notepad.
  • 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 on TechRepublic:

sudo service httpd start
sudo service httpd stop
sudo service httpd restart

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 executed.

The 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 "suite":

  • /etc/passwd - 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 user
    • home directory - The directory this account is set to upon login. The entry here included the path to the user's home directory.
    • login shell - The path to the shell that starts for the user account upon login
  • /etc/group - This file contains four fields of information about each group account:
    • 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
  • /etc/shadow - 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.
  • /etc/gshadow - 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 group members.
    • 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 in the /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 login attempts
  • LOG_OK_LOGINS - /etc/syslog.conf is set as the default file for successful login attempts
  • 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 a command)
  • 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 file
  • 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.