Linux Security
Linux security is a massive and complex topic so it is important to establish the intended scope of this section early on. The purpose of this section is two-fold. The first purpose is to familiarize you with basic Linux security operations that would enable you to effectively manage your development environment without being stumped. For example, you can’t execute a script unless your user on the system has the privileges to execute that script, based on the script’s file permissions and your group memberships. The second purpose of this section is to show you how to accomplish a minimal level of hardening for your development environment. Using an unsecured device to run scripts that access network devices–and possibly push configuration to those devices–is not a wise thing to do. Accordingly, this section covers user, group, file, and directory security, including access control lists. This chapter also covers the Linux firewall.
User and Group Management
Linux is a multiuser operating system, which means that more than one user can access a single Linux system at a time.
For a user to access a Linux system, the user’s account must be configured on the system. The user will then have a username and user ID (UID). A user with an account on the system is a member of one or more groups. Each group has a group name and a group ID (GID). By default, when a user is created on the system, a new group is also created; it has the same name as the username, and this becomes the primary group of the user. A user typically has a password, and each group also has a password.
Each user has a home directory that contains that user’s files. One way that Linux maintains user segregation and security is by maintaining permissions on files and directories and allowing users with the appropriate authorization level to set those permissions. File permissions are classified into permissions for the owner of the file, the group of the file, and everyone else. The root user and any other user with root privileges can access all resources on the system, including other users’ files and directories. The root user and users with root privileges are members of a group named wheel.
You can find user information by using the command id {username}, as shown in Example 3-16 for user NetProg.
Example 3-16 Getting User Information by Using the id Command
[root@localhost ~]# id NetProg uid=1001(NetProg) gid=1002(NetProg) groups=1002(NetProg),10(wheel) [root@localhost ~]#
User NetProg’s UID is 1001. The output in Example 3-16 shows that the user’s default (primary) group has the same name as the username. User NetProg in the example is also a member of the wheel group and therefore has root privileges that can be invoked by using the sudo {command} command, where command requires root privileges to be executed. The number to the left of each group name is the group ID.
User information is also stored in the /etc/passwd file, and group information is stored in the /etc/group file. Hashed user passwords are stored in the file /etc/shadow, and hashed group passwords are stored in the file /etc/gshadow. Example 3-17 displays the last five entries of each of the files.
Example 3-17 Last Five Entries from the /etc/passwd, /etc/group, /etc/shadow, and /etc/gshadow Files
! Sample entries from the /etc/passwd file [netdev@server1 ~]$ tail -n 5 /etc/passwd netdev:x:1000:1000:Network Developer:/home/netdev:/bin/bash vboxadd:x:970:1::/var/run/vboxadd:/bin/false cockpit-wsinstance:x:969:969:User for cockpit-ws instances:/nonexisting:/sbin/ nologin flatpak:x:968:968:User for flatpak system helper:/:/sbin/nologin rngd:x:967:967:Random Number Generator Daemon:/var/lib/rngd:/sbin/nologin [netdev@server1 ~]$ ! Sample entries from the /etc/group file [netdev@server1 ~]$ tail -n 5 /etc/group netdev:x:1000: vboxsf:x:970: cockpit-wsinstance:x:969: flatpak:x:968: rngd:x:967 [netdev@server1 ~]$ ! file /etc/shadow requires root privileges to be read [netdev@server1 ~]$ tail -n 5 /etc/shadow tail: cannot open '/etc/shadow' for reading: Permission denied [netdev@server1 ~]$ ! Sample entries from the /etc/shadow file [netdev@server1 ~]$ sudo tail -n 5 /etc/shadow [sudo] password for netdev: netdev:$6$.JUG9NvdC/NzqiYq$zpCkMR3eENFgk906PjFVLJ526qFRI9L2n13rFApiyPS0lgb2F1CTjJvc1 dqvvE3XV91q2fK.p3hvlEYtKciD2.:18489:0:99999:7::: vboxadd:!!:18473:::::: cockpit-wsinstance:!!:18473:::::: flatpak:!!:18473:::::: rngd:!!:18473:::::: [netdev@server1 ~]$ ! file /etc/gshadow requires root privileges to be read [netdev@server1 ~]$ tail -n 5 /etc/gshadow tail: cannot open '/etc/gshadow' for reading: Permission denied [netdev@server1 ~]$ ! Sample entries from the /etc/gshadow file [netdev@server1 ~]$ sudo tail -n 5 /etc/gshadow netdev:!:: vboxsf:!:: cockpit-wsinstance:!:: flatpak:!:: rngd:!:: [netdev@server1 ~]$
Each line in the /etc/passwd file is a record containing the information for one user account. Each record is formatted as follows: username:x:user_id:primary_group_id:user_extra_information:user_home_directory:user_default_shell.
The /etc/passwd and /etc/group files can be read by any user on the system but can only be edited by a user with root privileges. For this reason, as a security measure, the second field in the record, which historically contained the user password hash, now shows only the letter x. The user password hashes are now maintained in the /etc/shadow file, which can only be read by users with root privileges. The same arrangement is true for the /etc/group and the /etc/gshadow files. Whenever a user does not have a password, the x is omitted. Two consecutive colons in any record indicate missing information for the respective field.
Each line in the /etc/group file is a record containing information for one group. Each record is formatted as follows: groupname:x:group_id:group_members. The last field is a comma-separated list of non-default users in the group. For example, the record for the netdev group shows all users who are members of the group netdev except the user netdev itself.
Each line in the /etc/shadow file is a record containing the password information for one user. Each record is formatted as follows: username:password_hash:last_changed:min:max:warn:expired:disabled:reserved.
The field last_changed is the number of days between January 1, 1970, and the date the password was last changed. The field min is the minimum number of days to wait before the password can be changed. The value 0 indicates that it may be changed at any time. The field max is the number of days after which the password must be changed. The value 99999 means that the user can keep the same password practically forever. The field warn is the number of days to send a warning to the user prior to the password expiring. The field expired is the number of days after the password expires before the account should be disabled. The field disabled is the number of days since January 1, 1970, that an account has been disabled. The last field is reserved.
Finally, each line in the /etc/gshadow file is a record that contains the password information for one group. Each record is formatted as follows: groupname:group_password_ hash:group_admins:group_members. The group_password_hash field contains an exclamation symbol (!) if no user is allowed to access the group by using the newgrp command. (This command is covered later in this section.)
You use the command useradd {username} to create a new user, and the command passwd {username} to set or change the password for a user. After switching to user root by using the su command in Example 3-18, the id NetDev command is used to verify that user NetDev does not already exist. The new user NetDev is then created by issuing the command useradd NetDev.
Next, the example shows the su command being used to attempt to log in as user NetDev. Notice that although a password was requested, no password will actually work. This is because, by default, when a new user is created, a password entry is created in the /etc/shadow file, but until this password is actually set by using the passwd command, you cannot log in as the user because the default password hash in the shadow file is an invalid hash. The example shows the password being removed altogether with the command passwd -d NetDev. Only at this point are you able to log in without getting a password prompt. The password is then set using the command passwd NetDev, and a warning is displayed because the password entered was Cisco123. Once the password is set, it is possible to log in as the user in question. Note that creating a user also creates a home directory–in this case /home/NetDev–as shown in the output of the pwd command. The files /etc/passwd, /etc/group, and /etc/shadow are also updated to reflect the new user details, as shown in the example.
Example 3-18 Creating a New User and Setting the Password
[NetProg@localhost ~]$ su - Password: Last login: Sun Apr 15 14:26:29 +03 2018 on pts/1 [root@localhost ~]# ! Verify whether the user NetDev exists [root@localhost ~]# id NetDev id: NetDev: no such user [root@localhost ~]# ! Add user NetDev and log in to it [root@localhost ~]# useradd NetDev [root@localhost ~]# exit Logout [NetProg@localhost ~]$ ! Authentication will fail due to invalid "default" hash [NetProg@localhost ~]$ su NetDev Password: su: Authentication failure [NetProg@localhost ~]$ ! Switch back to user root and remove the password [NetProg@localhost ~]$ su - Password: Last login: Sun Apr 15 14:27:07 +03 2018 on pts/1 [root@localhost ~]# passwd -d NetDev Removing password for user NetDev. passwd: Success [root@localhost ~]# exit logout [NetProg@localhost ~]$ su NetDev [NetDev@localhost NetProg]$ exit Exit [NetProg@localhost ~]$ ! Switch to user root and set the password manually then test [NetProg@localhost ~]$ su - Password: Last login: Sun Apr 15 14:28:12 +03 2018 on pts/1 [root@localhost ~]# passwd NetDev Changing password for user NetDev. New password: BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word Retype new password: passwd: all authentication tokens updated successfully. [root@localhost ~]# exit logout [NetProg@localhost ~]$ su NetDev Password: [NetDev@localhost NetProg]$ ! Check the home directory and other details for user NetDev [NetDev@localhost NetProg]$ cd [NetDev@localhost ~]$ pwd /home/NetDev [NetDev@localhost ~]$ id NetDev uid=1002(NetDev) gid=1003(NetDev) groups=1003(NetDev) [NetDev@localhost ~]$ tail -n 1 /etc/passwd NetDev:x:1002:1003::/home/NetDev:/bin/bash [NetDev@localhost ~]$ tail -n 1 /etc/group NetDev:x:1003: [NetDev@localhost ~]$ ! Switch to user root and check file /etc/shadow [NetDev@localhost ~]$ su - Password: Last login: Sun Apr 15 14:50:37 +03 2018 on pts/0 [root@localhost ~]# tail -n 1 /etc/shadow NetDev:$6$y27JA0id$i8Wze1ShSptxy5wRS8f7fOkPeeAezo2cayDl/ sqikRkYp2VseEXNrzwqDQXqvMeAqzMs2Jd./jj5fm05PK.Wi/:17636:0:99999:7::: [root@localhost ~]# exit logout [NetDev@localhost ~]$
A user can change her own password by simply typing passwd without any arguments. The user is then prompted to enter the current password and then the new password and then to confirm the new password.
To delete a user, you use the command userdel {username}. This command deletes the user from the system; to delete that user’s home directory and print spool as well, you use the option -r with the command. You use the option -f to force the delete action even if the user is still logged in.
You can add groups separately from users by using the command groupadd {group_name}. You can use the option -g to set the GID manually instead of allowing automatic assignment of the next available GID. You delete groups by using the command groupdel {group_name}. Example 3-19 shows how to create a new group called engineers and set its GID to 1111.
Example 3-19 Creating a New Group engineers
[root@localhost ~]# tail -n 2 /etc/group NetProg:x:1002: NetDev:x:1003: [root@localhost ~]# groupadd -g 1111 engineers [root@localhost ~]# tail -n 3 /etc/group NetProg:x:1002: NetDev:x:1003: engineers:x:1111: [root@localhost ~]#
To delete a group, you use the command groupdel {group_name}. You change a group’s details by using the command groupmod. The command groupmod -g {new_gid} {group_name} changes the group gid to new_gid, and the command groupmod -n {new_name} {old_name} changes the group’s name from old_name to new_name. Finally, you change the group password by using the command gpasswd {group_name}. In Example 3-20, the group engineers is changed to NetDevOps, and its GID is changed to 2222. Then its password is modified to Cisco123.
Example 3-20 Modifying Group Details
[root@localhost ~]# tail -n -1 /etc/group engineers:x:1111: [root@localhost ~]# ! Change the group name to NetDevOps [root@localhost ~]# groupmod -n NetDevOps engineers [root@localhost ~]# tail -n -1 /etc/group NetDevOps:x:1111: [root@localhost ~]# ! Change the gid to 2222 [root@localhost ~]# groupmod -g 2222 NetDevOps [root@localhost ~]# tail -n -1 /etc/group NetDevOps:x:2222: [root@localhost ~]# ! Change the group password to Cisco123 [root@localhost ~]# gpasswd NetDevOps Changing the password for group NetDevOps New Password: Re-enter new password: [root@localhost ~]#
A user has one primary group and one or more secondary groups. A user’s primary group is the group that the user is placed in when logging in. You modify user group membership by using the command usermod. To change a user’s primary group, you use the syntax usermod -g {primary_group} {username}. To change a user’s secondary group, you use the syntax usermod -G {secondary_group} {username}; note that this command removes all secondary group memberships for this user and adds the group secondary_ group specified in the command. To add a user to a secondary group while maintaining his current group memberships, you use the syntax usermod -aG {new_secondary_ group} {username}. To lock a user account, you use the option -L with the usermod command, and to unlock an account, you use the -U option with this command. Example 3-21 shows how to change the primary group of user NetDev from NetDev to NetOps and add the wheel group to the list of secondary groups to give the user root privileges through the sudo command.
Example 3-21 Modifying User Details
[root@localhost ~]# id NetDev uid=1002(NetDev) gid=1003(NetDev) groups=1003(NetDev) [root@localhost ~]# usermod -g NetOps NetDev [root@localhost ~]# id NetDev uid=1002(NetDev) gid=2222(NetOps) groups=2222(NetOps) [root@localhost ~]# usermod -aG wheel NetDev [root@localhost ~]# id NetDev uid=1002(NetDev) gid=2222(NetOps) groups=2222(NetOps),10(wheel) [root@localhost ~]#
Notice that when the -g option is used to change the primary group, the secondary group is also changed. This is because user NetDev was only a member of a single group, NetDev, and that group was both the user’s primary group and secondary group. When the primary and secondary groups are different, the -g option changes only the primary group of the user.
File Security Management
Chapter 2 describes the output of the ls -l command and introduces file permissions, also known as the file mode bits. This section builds on that introduction and expands on how to manage access to files and directories by modifying their permissions. It also discusses changing the file owner (user) and group. Keep in mind that in Linux, everything is represented by a file. Therefore, the concepts discussed here have a wider scope than what seems to be obvious. Also, whenever a reference is made to a file, the same concept applies to a directory, unless explicitly stated otherwise.
Example 3-22 shows the output of ls -l for the NetProg home directory.
Example 3-22 Output of the ls -l Command
[NetProg@localhost ~]$ ls -l total 0 drwxr-xr-x. 2 NetProg NetProg 40 Apr 9 09:41 Desktop drwxr-xr-x. 2 NetProg NetProg 6 Mar 31 17:34 Documents drwxr-xr-x. 2 NetProg NetProg 6 Mar 31 17:34 Downloads drwxr-xr-x. 2 NetProg NetProg 6 Mar 31 17:34 Music drwxr-xr-x. 2 NetProg NetProg 6 Mar 31 17:34 Pictures drwxr-xr-x. 2 NetProg NetProg 6 Mar 31 17:34 Public drwxrwxr-x. 2 NetProg NetProg 183 Apr 7 22:53 Scripts drwxr-xr-x. 2 NetProg NetProg 6 Mar 31 17:34 Templates -rw-rw-r--. 1 NetProg NetProg 0 Apr 9 17:51 Testfile.txt drwxr-xr-x. 2 NetProg NetProg 6 Mar 31 17:34 Videos [NetProg@localhost ~]$
Here is a quick recap on the file permissions: The very first bit indicates whether this is a file (-), a directory (d), or a link (l). Then the following 3 bits define the permissions for the file owner. By default, the owner is the user who created the file. The following 3 bits define the permissions for the users who are members of the file group. By default, this is the primary group of the user who created the file. The last 3 bits define the permissions for everyone else, referred to as other. The letter r stands for read permission, w for write permission, and x for execute permission.
The dot right after the mode bits indicates that this file has an SELinux context. SELinux is a kernel security module that defines the access rights of every user, application, process, and file on the system. SELinux then governs the interactions of these entities using a security policy, where an entity referred to as a subject attempts to access another entity referred to as an object. SELinux is an important component of Linux security but is beyond the scope of this book. When a file or a directory has a + symbol in place of the dot (.), it means the file has an access control list (ACL) applied to it. ACLs, which are covered later in this chapter, provide more granular access control to files on a per-user basis.
The output of the ls -l command also displays the file owner (more formally referred to as user) and the file group.
File permissions can be represented (and modified) by either using symbolic notation or octal notation.
Symbolic notation is the type of notation described so far, where user, group, and others are represented by u, g, and o, respectively, and the access permissions are write, read, and execute, represented by w, r, and x, respectively. The following syntax is used to set the file permissions: chmod [u={permissions}][,g={permissions}][,o={permissions}] {file_name}.
Example 3-23 shows how to modify the file permissions for file TestFile.txt to the following:
User: Read, write, and execute
Group: Read and write
Other: No access
Example 3-23 Setting File Permissions by Using Symbolic Notation
! Current file permissions [NetProg@localhost ~]$ ls -l Testfile.txt -rw-rw-r--. 1 NetProg NetProg 0 Apr 9 17:51 Testfile.txt [NetProg@localhost ~]$ ! Change the file permissions as listed [NetProg@localhost ~]$ chmod u=rwx,g=rw,o= Testfile.txt ! New file permissions [NetProg@localhost ~]$ ls -l Testfile.txt -rwxrw----. 1 NetProg NetProg 0 Apr 9 17:51 Testfile.txt [NetProg@localhost ~]$
Notice that in order to remove all permissions for one of the categories, you just leave the right side of the = symbol blank.
One of the challenges with the symbolic notation syntax as used in Example 3-23 is that you have to know beforehand what permissions the file already has and make sure to align the current permissions with the new permissions you are trying to set. For example, if a file already has read and write permissions set for the file group and you would like to add the execute permission, you have to know this fact prior to the change, and then you need to make sure you do not delete the already existing write or read permissions while setting the execute permission. In order to just add or remove permissions for a specific category, without explicitly knowing or considering the existing permissions, you replace the = symbol in the previous syntax with either a + or a - symbol, as follows: chmod [u[+|-]{permissions}][,g[+|-]{permissions}][,o[+|-]{permissions}] {file_name}.
In Example 3-24 the permissions for the file TestFile.txt are modified as follows:
User: Unchanged
Group: Write permission removed and execute permission added
Other: Execute permission added
Notice that when using this syntax, you do not need to know what permissions the file already has. You only need to consider the changes that you want to implement.
Example 3-24 Adding and Removing File Permissions by Using Symbolic Notation
[NetProg@localhost ~]$ ls -l Testfile.txt -rwxrw----. 1 NetProg NetProg 0 Apr 9 17:51 Testfile.txt [NetProg@localhost ~]$ chmod g-w,g+x,o+x Testfile.txt [NetProg@localhost ~]$ ls -l Testfile.txt -rwxr-x--x. 1 NetProg NetProg 0 Apr 9 17:51 Testfile.txt [NetProg@localhost ~]$
Notice that you can mix the + and - symbols in the same command and for the same category, as shown in Example 3-24 for the file group, where g-w is used to remove the write permission for the group, and g+x is used to add the execute permission for the group.
When a certain permission has to be granted or revoked from all categories, the letter a is used to collectively mean u, g, and o. The letter a in this case stands for all. The letter a may be dropped altogether, and the command then applies to all categories. For example, the command chmod +w Example.py adds the write permission to all categories for the file Example.py.
Octal notation, on the other hand, uses the following syntax: chmod {user_permission}{group_permission}{other_permission} {file_name}. The user, group, and other categories are represented by their positions in the command. The permission granted to each category is represented as a numeric value that is equal to the summation of each permission’s individual value. To elaborate, note the following permission values:
Read=4
Write=2
Execute=1
To set the read permission only, you need to use the value 4; for write permission only, you use the value 2; and for execute permission only, you use the value 1. To set all permissions for any category, you need to use 4+2+1=7. To set the read and write permissions only, you need to use 4+2=6, and so forth. Example 3-25 illustrates this concept and uses octal notation to set the read, write, and execute permissions for both user and group, and set only the execute permission for the category other for file Testfile.txt.
Example 3-25 Setting File Permissions Using Octal Notation
[NetProg@localhost ~]$ ls -l Testfile.txt -rwxr-x--x. 1 NetProg NetProg 0 Apr 9 17:51 Testfile.txt [NetProg@localhost ~]$ chmod 771 Testfile.txt [NetProg@localhost ~]$ ls -l Testfile.txt -rwxrwx--x. 1 NetProg NetProg 0 Apr 9 17:51 Testfile.txt [NetProg@localhost ~]$
The number 7 in each of the first two positions in the command chmod 771 Testfile.txt represents the sum of 4, 2, and 1 and is used to set all permissions for user and group. The number 1 in the last position sets the execute only permission for other.
While octal notation looks snappier than symbolic notation, it does not provide the option of adding or removing permissions without considering the existing file permissions, as provided by the + and - symbols used with symbolic notation.
Besides modifying file and directory permissions, you can control access to a file or directory by changing the file’s user and/or group through the chown command. The command syntax is chown {user}:{group} {file}. Example 3-26 shows how to change the user and group of file TestFile.txt to NetDev and networks, respectively.
Example 3-26 Changing File User and Group by Using the chown Command
[root@localhost ~]# ls -l /home/NetProg/Testfile.txt -rwxrwx--x. 1 NetProg NetProg 0 Apr 9 17:51 /home/NetProg/Testfile.txt [root@localhost ~]# chown NetDev:networks /home/NetProg/Testfile.txt [root@localhost ~]# ls -l /home/NetProg/Testfile.txt -rwxrwx--x. 1 NetDev networks 0 Apr 9 17:51 /home/NetProg/Testfile.txt [root@localhost ~]#
You use the -R option (which stands for recursive) with both the chmod and the chown commands if the operation is being performed on a directory, and you want the changes to also be made to all subdirectories and files in that directory.
By default, any file or directory created by a user is assigned to the primary group of that user. For example, if user NetDev is in the NetOps group, any file created by user NetDev has NetDev as the file user and NetOps as the file group. You can change this default behavior by either using the sg command when creating the file or by logging in to another group by using the command newgrp. If that other group is one of the user’s secondary groups, no password is required. If that other group is not one of the user’s secondary groups, the user is prompted for a password.
Example 3-27 shows the default behavior when creating a file. In this case, a new file named NewFile is created by user NetDev. As expected, the file user is NetDev, and the file group is NetOps.
Example 3-27 Default User and Group of a Newly Created File
[NetDev@localhost ~]$ id NetDev uid=1002(NetDev) gid=2222(NetOps) groups=2222(NetOps),10(wheel) [NetDev@localhost ~]$ touch NewFile [NetDev@localhost ~]$ ls -l NewFile -rw-r--r--. 1 NetDev NetOps 0 Apr 17 00:59 NewFile [NetDev@localhost ~]$
Example 3-28 shows how to use the sg command to create file NewFile_1 but under the group networks.
Example 3-28 Using the sg Command to Create a File Under a Different Group
[NetDev@localhost ~]$ id NetDev uid=1002(NetDev) gid=2222(NetOps) groups=2222(NetOps),10(wheel) [NetDev@localhost ~]$ sg networks 'touch NewFile_1' Password: [NetDev@localhost ~]$ ls -l NewFile_1 -rw-r--r--. 1 NetDev networks 0 Apr 17 01:03 NewFile_1 [NetDev@localhost ~]$
Notice that the command touch {file_name}, which itself is an argument to the sg command, has to be enclosed in quotes because it is a multi-word command. Notice also that because the user NetDev is not a member in the networks group, as you can see from the output of the id command, the user is prompted for the group password, which was set earlier by using the command gpasswd networks.
Alternatively, the user can log in to another group by using the command newgrp and create a file or directory under that group. Example 3-29 shows the user NetProg logging in to group systems and not being prompted for a password since this is one of NetProg’s secondary groups. When the file NewFile_2 is created, the user of the file is NetProg, and the group is systems, not NetProg.
Example 3-29 Using the newgrp Command to Log In to a Different Group
[NetProg@localhost ~]$ id NetProg uid=1001(NetProg) gid=1002(NetProg) groups=1002(NetProg),10(wheel),2224(systems) [NetProg@localhost ~]$ newgrp systems [NetProg@localhost ~]$ touch NewFile_2 [NetProg@localhost ~]$ ls -l NewFile_2 -rw-r--r--. 1 NetProg systems 0 Apr 17 01:15 NewFile_2 [NetProg@localhost ~]$
Access Control Lists
So far in this chapter, you have seen how to set file and directory access permissions for either user, or collectively for group, or other. What if you want to set those permissions individually for a specific user who is not the file owner or for a group of users who belong to a group other than the file group? File mode bits do not help in such situations. Using the file mode bits, the only user whose permissions can be changed individually is the file or directory owner (user) and the only group of users whose permissions can be changed collectively are the users who are members of the file or directory group.
Access control lists (ACLs) provide more granular control over file and directory access. ACLs allow a system administrator (or any other user who has root privileges) to set file and directory permissions for any user or group on the system.
Before you can configure ACLs, three prerequisites must be met:
The kernel must support ACLs for the file system type on which ACLs will be applied.
The file system on which ACLs will be used must be mounted with the ACL option.
The ACL package must be installed.
Most common distros today–including CentOS 7 and Red Hat Enterprise Linux (RHEL) 7 and later versions–have these prerequisites configured by default, and you do not need to do any further configuration.
If you are running a different distro or an older version of CentOS, you can check the first prerequisite by using either the findmnt or blkid command to determine the file system type on your system. The command findmnt works only if the file system has been mounted, and blkid works whether it is mounted or not. Then you need to inspect the kernel configuration file /boot/conf-<version.architecture> to determine whether ACLs have been enabled for this file system type. Example 3-30 shows the relevant output for the file system on the sda1 partition.
Example 3-30 ACL Support for the sda1 File System
[root@server1 ~]# findmnt /dev/sda1 TARGET SOURCE FSTYPE OPTIONS /boot /dev/sda1 xfs rw,relatime,seclabel,attr2,inode64,noquota [root@server1 ~]# cat /boot/config-3.10.0-693.el7.x86_64 | grep ACL CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_XFS_POSIX_ACL=y CONFIG_BTRFS_FS_POSIX_ACL=y CONFIG_FS_POSIX_ACL=y CONFIG_GENERIC_ACL=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_NFS_V3_ACL=y CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3_ACL=y CONFIG_NFS_ACL_SUPPORT=m CONFIG_CEPH_FS_POSIX_ACL=y CONFIG_CIFS_ACL=y [root@server1 ~]#
The kernel configuration file lists different configuration options, each followed by an = symbol and then the letter y, n, or m. The letter y means that this option (module) was configured as part of the kernel when the kernel was first compiled. In this example, CONFIG_XFS_POSIX_ACL=y means that the kernel supports ACLs for the xfs file system. The letter n indicates that this module was not compiled into the kernel, and the letter m means that this module was compiled as a loadable kernel module (introduced in Chapter 2).
The second prerequisite is that the partition on which the ACLs will be used has to be mounted with the ACL option. By default, on ext3/4 and xfs file systems, ACL support is enabled. In older CentOS versions and other distros where the ACL option is not enabled by default, the file system can be mounted with the ACL option by using the syntax mount -o acl {partition} {mount_point}. On the other hand, if the ACL option is enabled by default, and you want to disable ACL support while mounting the file system, you can use the noacl option with the mount command. As discussed in the previous section, mounting using the mount command is non-persistent. For persistent mounting with the ACL option, you can add an entry to the /dev/fstab file (or amend an existing entry) and add the acl option (right after the defaults keyword). The /dev/fstab file is discussed in detail earlier in this chapter.
Finally, by using the yum info acl command, you can confirm whether the ACL package has been installed. The yum command is covered in detail in Chapter 2.
When ACL support has been established, you can use the command getfacl {filename| directory} to display the ACL configuration for a file or directory. Example 3-31 shows the output of the getfacl command for the directory /Programming and then for the file NewFile.txt.
Example 3-31 Output of the getfacl Command
[root@localhost /]# ls -ld Programming drwxr-xr-x. 2 root root 25 Jun 9 05:46 Programming [root@localhost /]# ls -l Programming total 0 -rw-r--r--. 1 root root 0 Jun 9 05:46 NewFile.txt [root@localhost /]# getfacl Programming # file: Programming # owner: root # group: root user::rwx group::r-x other::r-x [root@localhost /]# getfacl Programming/NewFile.txt # file: Programming/NewFile.txt # owner: root # group: root user::rw- group::r-- other::r– [root@localhost /]#
As you can see from the output in Example 3-31, both the directory and file are owned by the user root, and the group of both is also root. So far, there is no additional information provided by the getfacl command beyond what is already displayed by ls -l; the format is the only difference.
For the file NewFile.txt, the user NetProg is not the file owner and is not a member of the file group. As per the permissions for other, the user NetProg should be able to only read the file but not write to it or execute it. In Example 3-32, the user NetProg attempts to write to the file NewFile.txt by using the echo command, but a “Permission denied” error message is displayed. The setfacl -m u:NetProg:rw /Programming/Newfile.txt command grants write permission to the user NetProg. When the write operation is attempted again, it is successful due to the new elevated permissions.
Example 3-32 Changing the Permissions for the User NetProg by Using setfacl
! Echo(write) operation fails since NetProg has no write permissions [NetProg@localhost /]$ echo "This is a write test" > /Programming/NewFile.txt bash: /Programming/NewFile.txt: Permission denied ! Grant user NetProg write permission (requires root permissions) [NetProg@localhost /]$ su Password: [root@localhost /]# setfacl -m u:NetProg:rw /Programming/NewFile.txt [root@localhost /]# getfacl /Programming/NewFile.txt getfacl: Removing leading '/' from absolute path names # file: Programming/NewFile.txt # owner: root # group: root user::rw- user:NetProg:rw- group::r-- mask::rw- other::r-- ! Write operation now successful [root@localhost /]# su NetProg [NetProg@localhost /]$ echo "This is a write test" > /Programming/NewFile.txt [NetProg@localhost /]$ cat /Programming/NewFile.txt This is a write test [NetProg@localhost /]$ ls -l /Programming/NewFile.txt -rw-rw-r--+ 1 root root 21 Jun 9 07:24 /Programming/NewFile.txt [NetProg@localhost /]$
Notice the + symbol that now replaces the dot to the right of file permission bits at the end of Example 3-32. This indicates that an ACL has been applied to this file. The new write permission has been granted to the user NetProg only, and not to any other user. This was done without amending the file permissions for the user, group, or other categories. It was also done without modifying the group memberships of the user NetProg. The same permission could also be applied to a group instead of an individual user. The level of granularity provided by ACLs should be clear by now.
The setfacl command used in Example 3-32 was issued with the option -m, which is short for modify and is used to apply a new ACL or modify an existing ACL. To remove an ACL, you use the option -x instead of -m; the remainder of the command remains the same, except that the ACL in the command is an existing ACL that is now being removed.
In Example 3-32 you can see the three-field argument u:NetProg:rw. When setting an ACL for a user, the first field is u, as in the example. For a group, the first field would be g, and for other, the first field would be o. The second field is the user or group name, which is NetProg in this example. If the ACL is for other, this field remains empty. The third field is the permissions you wish to grant to the user or group.
Finally, after the three-field argument is the name of the directory or file to which the ACL is applied. Note that whether a full path or only a relative path is required depends on the current working directory relative to the location of the file or directory to which the ACL is being applied. The same rules apply here as with any other Linux command that operates on a file or directory.
Therefore, the general syntax of the setfacl command to add, modify, or remove an ACL is setfacl {-m|-x} {u|g|o}:{username|group}:{permissions} {file|directory}. To remove all ACL entries applied to a file, you use the option -b followed by the filename, omitting the three-field argument.
In Example 3-32, notice the text mask::rw- in the output of the getfacl command, after the ACL has been applied. The mask provides one more level of control over the permissions granted by the ACL. Say that after granting several users different permissions to a file, you decide to remove a specific permission, such as the write permission, from all named users. The ACL mask then comes in handy. The permissions in the mask override the permissions for all named users and the file group. For example, if the mask permissions are r-x and the user NetProg has been granted rwx permissions, that user’s effective permissions are r-x after the mask is set. The effective mask permissions are applied using the command setfacl -m m:{permissions} {filename}. In Example 3-33, the user NetProg has permissions rw-, and so does the mask. The mask is modified to r--. Notice the effective permissions that appear on the right side of the output of the getfacl command after the mask has been modified. After you remove the write permission from the mask, NetProg’s write attempt to the file fails.
Example 3-33 Changing the Mask Permissions by Using setfacl
! Set the effective rights mask [root@localhost /]# setfacl -m m:r /Programming/NewFile.txt [root@localhost /]# getfacl /Programming/NewFile.txt getfacl: Removing leading '/' from absolute path names # file: Programming/NewFile.txt # owner: root # group: root user::rw- user:NetProg:rw- #effective:r-- group::r-- mask::r-- other::r-- ! Write operation to file by user NetProg now fails [root@localhost /]# su NetProg [NetProg@localhost /]$ echo "Testing mask permissions" > /Programming/NewFile.txt bash: /Programming/NewFile.txt: Permission denied [NetProg@localhost /]$
When ACLs are applied to directories, by default, these ACLs are not inherited by files and subdirectories in that directory. In order to achieve inheritance, the option -R has to be added to the same setfacl command used earlier. In Example 3-34, an ACL setting rwx permissions for the user NetProg is applied to the directory Programming. Attempting to write to file NewFile.txt under the directory by user NetProg fails because the write permission has not been inherited by the file.
Example 3-34 ACLs Are Not Inherited by Default by Subdirectories and Files Under a Directory
! Apply an acl to the /Programming directory [root@localhost ~]# setfacl -m u:NetProg:rwx /Programming [root@localhost ~]# getfacl /Programming getfacl: Removing leading '/' from absolute path names # file: Programming # owner: root # group: root user::rwx user:NetProg:rwx group::r-x mask::rwx other::r-x ! The acl is not applied to NewFile.txt under the directory [root@localhost ~]# getfacl /Programming/NewFile.txt getfacl: Removing leading '/' from absolute path names # file: Programming/NewFile.txt # owner: root # group: root user::rw- group::r-- other::r-- ! And the write operation fails as expected [root@localhost ~]# su - NetProg [NetProg@localhost ~]$ echo "This is a write test" > /Programming/NewFile.txt bash: /Programming/NewFile.txt: Permission denied [NetProg@localhost ~]$
After the ACL has been removed and then reapplied in Example 3-35 using the -R option, the user NetProg can write to the file successfully. The getfacl command also shows that the ACL has been applied to the file as if the setfacl command had been applied to the file directly.
Example 3-35 ACL Inheritance by Subdirectories and Files Under a Directory Using the -R Option
! Clear the acl from the /Programming directory [root@localhost ~]# setfacl -b /Programming ! Apply the acl to directory /Programming using the -R option [root@localhost ~]# setfacl -R -m u:NetProg:rwx /Programming [root@localhost ~]# getfacl /Programming getfacl: Removing leading '/' from absolute path names # file: Programming # owner: root # group: root user::rwx user:NetProg:rwx group::r-x mask::rwx other::r-x ! The acl is inherited by the file NewFile.txt [root@localhost ~]# getfacl /Programming/NewFile.txt getfacl: Removing leading '/' from absolute path names # file: Programming/NewFile.txt # owner: root # group: root user::rw- user:NetProg:rwx group::r-- mask::rw- other::r-- ! And the write operation is successful [root@localhost ~]# su - NetProg [NetProg@localhost ~]$ echo "This is to test inheritance" > /Programming/NewFile.txt [NetProg@localhost ~]$ cat /Programming/NewFile.txt This is to test inheritance [NetProg@localhost ~]$
It is important to remember that the ACL applied to a directory and inherited by all subdirectories and files will not be applied to any files created after the ACL has been applied. Only the files that existed before the ACL was applied will be affected.
The ACLs described so far are called access ACLs. Another type of ACLs, called default ACLs, may be used with directories (only) if the requirement is that all files and subdirectories, when created, should inherit the parent directory ACLs. The syntax for applying a default ACL is setfacl -m d:{u|g|o}:{username|group}:{permissions} {directory}. Try to experiment with default ACLs and note how newly created files inherit the directory ACL without your having to explicitly issue the setfacl command after the file or subdirectory has been created.
The same concepts discussed previously for a single user apply to a group when you set the ACL for a group of users other than the file or directory group by using the letter g along with the group name in the setfacl command instead of a u with the username.
In addition to using the setfacl command to set permissions for a specific user or group, you can use this command to set permissions for the file user, group, or other categories, similar to what can be accomplished using the chmod command as shown in the previous section. Note that if the setfacl command is used to apply an ACL to a file or directory, it is recommended that you not use chmod.
When a file or directory is copied or moved, ACLs are moved along with the file or directory.
Linux System Security
CentOS 7 and later versions come with a default built-in firewall service named firewalld. This service functions in a similar manner to a regular firewall in terms of providing security zones with different trust levels. Each zone constitutes a group of permit/deny rules for incoming traffic. Each physical interface on the server is bound to one of the firewall zones. However, firewalld provides only a subset of the services provided by a full-fledged firewall.
You can check the status of the firewalld service and start, stop, enable, and disable the service just as you would any other service on Linux by using the systemctl command. Example 3-36 shows the status of the firewalld service: In this example, you can see that it is active and enabled.
Example 3-36 The firewalld Service Status
[NetProg@localhost ~]$ systemctl status firewalld
• firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor
preset: enabled)
Active: active (running) since Sat 2018-04-21 21:37:06 +03; 30min ago
Docs: man:firewalld(1)
Main PID: 787 (firewalld)
CGroup: /system.slice/firewalld.service
|__787 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid
Apr 21 21:37:05 localhost.localdomain systemd[1]: Starting firewalld - dynamic
firewall daemon...
Apr 21 21:37:06 localhost.localdomain systemd[1]: Started firewalld - dynamic
firewall daemon.
--------- OUTPUT TRUNCATED FOR BREVITY ---------
The firewalld service has a set of zones created by default when the service is first installed; these zones are sometimes referred to as the base or predefined zones. Custom zones can also be created and deleted. However, base zones cannot be deleted. One zone is designated as the default zone and is the zone to which all interfaces are bound, by default, unless the interface is explicitly moved to another zone. By default, the default zone is the public zone. Each zone has a set of rules attached to it and a list of interfaces bound to it. Rules and interfaces can be added to or removed from a zone.
Example 3-37 shows how to list the base zones of firewalld by using the command firewall-cmd --get-zones and how to identify the default zone by using the command firewall-cmd --get-default-zone.
Example 3-37 Listing the Base and Default Zones of a Firewall
[root@localhost ~]# firewall-cmd --get-zones block dmz drop external home internal public trusted work [root@localhost ~]# firewall-cmd --get-default-zone public [root@localhost ~]#
You can change the default zone by using the command firewall-cmd --set-default-zone={zone_name}.
You can list the details of a zone by using the command firewall-cmd --list-all --zone={zone_name}, as shown in Example 3-38. To list the details of the default zone, you omit the --zone={zone_name} option.
Example 3-38 Listing Zone Details
[root@localhost ~]# firewall-cmd --list-all --zone=internal internal target: default icmp-block-inversion: no interfaces: sources: services: ssh mdns samba-client dhcpv6-client ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@localhost ~]# firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: enp0s3 enp0s9 enp0s10 enp0s8 sources: services: ssh dhcpv6-client ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@localhost ~]#
Example 3-39 shows how to add rules to the zone dmz to permit specific incoming traffic on interfaces bound to this zone. The first rule added permits traffic from the source IP address 10.10.1.0/24 by using a source-based rule. Then BGP traffic on TCP port 179 is permitted by using a port-based rule. HTTP service is then permitted by defining a service-based rule. Finally, interface enp0s9 is removed from the public zone and bound to the dmz zone. Notice how the rules appear when the details of the zone are listed at the end of the example.
Example 3-39 Adding Rules to Zone dmz
[root@localhost ~]# firewall-cmd --list-all --zone=dmz dmz target: default icmp-block-inversion: no interfaces: sources: services: ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@localhost ~]# firewall-cmd --zone=dmz --add-source=10.10.1.0/24 success [root@localhost ~]# firewall-cmd --zone=dmz --add-port=179/tcp success [root@localhost ~]# firewall-cmd --zone=dmz --add-service=http success [root@localhost ~]# firewall-cmd --zone=dmz --add-interface=enp0s9 The interface is under control of NetworkManager, setting zone to 'dmz'. success [root@localhost ~]# firewall-cmd --zone=dmz --list-all dmz (active) target: default icmp-block-inversion: no interfaces: enp0s9 sources: 10.10.1.0/24 services: ssh http ports: 179/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@localhost ~]#
Note that in order to remove a rule, instead of using the --add option, you use the --remove option. For example, to remove the rule for TCP port 179, you use the command firewall-cmd --zone=dmz --remove-port=179/tcp.
Much like running and startup configurations on routers and switches, firewalld supports both runtime and permanent configurations. A runtime configuration is not persistent and is lost after a reload. A permanent configuration is persistent but takes effect only after a reload when the configuration has been changed. Any configuration commands that have been executed are reflected in the runtime configuration. To make a configuration permanent, you use the option --permanent with the command. You reload the firewalld service by using the command firewall-cmd --reload.