Certification Objective 4.04-Access Control Lists and Other Security Attributes

Three of the methods for protecting individual files in Linux are based on file permissions, access control lists, and SELinux. File permissions are the standard method for security control, regulating access by user, group, and others. It's a basic prerequisite described in Chapter 1. With access control lists, file owners can regulate permissions for specific users. You can control SELinux from the command line; however, as described in Chapter 15, it's easier to control with the SELinux Management tool.

Exam Watch

Although ACLs and SELinux have just been added to the Red Hat Exam Prep guide, they have already been part of the course outline associated with both the RHCT and RHCE exams.

Access Control Lists

There was a time where users had read access to the files of all other users. But by default, users have permissions only in their own directories. Before you can configure ACLs, you'll need to set up execute permissions on the associated directories. For example, when I want to configure access to Donna's home directory, I first need to set appropriate permissions with the following command:

 # chmod 701 /home/donna 

The control associated with regular permissions is limited; the right ACLs can allow administrators to grant read, write, and execute access to a variety of users and groups.

Configuring a Filesystem for ACLs

Before you can configure a file or directory with ACLs, you need to mount the associated filesystem with the same attribute. If you're just testing a system for ACL, you can remount an existing partition appropriately. For example, if /home is mounted on /dev/sda3, I can remount it with ACL using the following command:

 # mount -o remount -o acl /dev/sda3 /home 

Naturally, to make sure this is the way /home is mounted on the next reboot requires editing /etc/fstab; for the noted parameters, the applicable line might read:

 /dev/sda3     /home     ext3     defaults,acl     1,2 

Depending on your configuration, you might see LABEL=/home in place of /dev/sda3.

Working with ACLs

Now with a properly mounted filesystem and appropriate permissions, you can manage ACLs on your system. To review default ACLs, run the getfacl filename command. For this example, I've created a text file named abc in Donna's home directory, and I get the following result:

 # getfacl /home/donna/abc # file: home/donna/abc # owner: donna # group: donna user::rw- group::rw- other::r-- 

Now when I assign ACLs for the file named abc for myself (user Michael), I first need to assign appropriate ACLs for the /home/donna directory. The following command sets the ACLs, which support read and execute permissions for myself on Donna's home directory, as well as an effective rights mask that should equal or exceed the user ACLs.

 # setfacl -m user:michael:r-x /home/donna # setfacl -m mask:r-x /home/donna 

Now I can configure individual files with ACLs. First, I deny access to all users but the owner:

 # chmod 700 /home/donna/abc 

To check the result, I log into my own account and try opening abc from Donna's home directory. I get the [permission denied] message.

Now I set the ACLs for file abc with the following commands:

 # setfacl -m user:michael:r-- /home/donna/abc # setfacl -m mask:r-x /home/donna/abc 

Now I can open /home/donna/abc from my own account. Now here's a question for you-what change would you make to the previous commands to make abc writable from the user michael account?

Understanding SELinux

The controls associated with SELinux are described in more detail in Chapter 15. This chapter serves as a basic overview of SELinux and describes what associated policies can do.

SELinux was first developed by the US National Security Agency (NSA) as patches to the Linux kernel to provide a different level of "mandatory access control." Once it was released under an open-source license, Linux developers integrated SELinux into every process.

Red Hat implements SELinux with a targeted level of enforcement. In other words, SELinux in RHEL protects targeted network daemons. Thus, when you run SELinux and a firewall, you'll need to configure access through the firewall and create SELinux settings that enable the daemon (and probably more distinct settings such as access to certain directories).

To review SELinux security contexts in the current directory, run the ls -Z command. When I run it in my home directory, I get the following output:

 drwxr-xr-x mike mike user_u:object_r:user_home_t   Desktop -rw-r--r-- mike mike user_u:object_r:user_home_t   f1505.tif 

If you're familiar with the output to ls -l, you should recognize some of the output from the ls -Z command; the first bits specify permissions and ownership, and the last bits specify the name of the file or directory. The SELinux context is:

 user_u:object_r:user_home_t 

This specifies the identity, role, and domain associated with the file. Typical options for identity are user_u, root, and system_u, which naturally correspond to generic users, the root user, and system users, respectively. Every file I've checked on my Red Hat system is associated with the object_r role. The domain is most variable and is most closely associated with the settings used to control SELinux. This domain is different from any sort of DNS or Microsoft domain and can be very specific: for example, the domain for the ping command is ping_exec_t; the domain associated with the default FTP server directory (/var/ftp/pub) is public_context_t. If you want to support FTP write access to that directory, you'll need to change the domain to public_context_rw_t.

For a more complete discussion of how RHEL implements SELinux, see the Security and Authentication manual available from www.redhat.com.