Chapter 5. Mastering Discretionary Access Control
Discretionary Access Control, DAC, really just means that each user has the ability to control who can get into his or her stuff. If I wanted to open my home directory so that every other user on the system can get into it, I could do that. Having done so, I could then control who can access each specific file. In the next chapter, we'll use our DAC skills to manage shared directories, where members of a group might need different levels of access to the files within.
By this point in your Linux career, you likely know the basics of controlling access by setting file and directory permissions. In this chapter, we'll do a review of the basics, and then we'll look at some more advanced concepts. Topics that we'll cover include:
- Using
chown
to change the ownership of files and directories - Using
chmod
to set permissions on files and directories - What SUID and SGID settings can do for us on regular files
- The security implications of having the SUID...
Using chown to change ownership of files and directories
Controlling access to files and directories really just boils down to ensuring that the proper users own files and directories, and that each file and directory has permissions set in such a way that only authorized users can access them. The chown
utility covers the first part of this equation.
One unique thing about chown
is that you must have sudo privileges to use it, even if you're working with your own files in your own directory. You can use it to change the user of a file or directory, the group that's associated with a file or directory, or both at the same time.
First, let's say that you own the perm_demo.txt
file and you want to change both the user and group association to that of another user. In this case, I'll change the file ownership from me to Maggie:
[donnie@localhost ~]$ ls -l perm_demo.txt
-rw-rw-r--. 1 donnie donnie 0 Nov 5 20:02 perm_demo.txt
[donnie@localhost ~]$ sudo chown maggie:maggie perm_demo.txt
[donnie...
Using chmod to set permissions values on files and directories
On Unix and Linux systems, you would use the chmod
utility to set permissions values on files and directories. You can set permissions for the user of the file or directory, the group that's associated with the file or directory, and others. The three basic permissions are:
r
: This indicates a read permission.w
: This is for a write permission.x
: This is the executable permission. You can apply it to any type of program file, or to directories. If you apply an executable permission to a directory, authorized people will be able to cd
into it.
Do an ls -l
on a file, and you'll see something like this:
-rw-rw-r--. 1 donnie donnie 804692 Oct 28 18:44 yum_list.txt
The first character of this line indicates the type of file. In this case, we see a dash, which indicates a regular file. (A regular file is pretty much every type of file that a normal user would be able to access in his or her daily routine.) The next three characters...
Using SUID and SGID on regular files
When a regular file has its SUID permission set, whoever accesses the file will have the same privileges as the user of the file. When the SGID permission is set on a regular file, whoever accesses the file will have the same privileges as the group that's associated with the file. This is especially useful on program files.
To demo this, let's say that Maggie, a regular, unprivileged user, wants to change her own password. Since it's her own password, she would just use the one-word command, passwd
, without using sudo
:
[maggie@localhost ~]$ passwd
Changing password for user maggie.
Changing password for maggie.
(current) UNIX password:
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[maggie@localhost ~]$
To change a password, a person has to make changes to the /etc/shadow
file. On my CentOS machine, the shadow file permissions look like this:
[donnie@localhost etc]$ ls -l shadow
----------. 1 root root 840 Nov...
The security implications of the SUID and SGID permissions
As useful as it may be to have SUID or SGID permissions on your executable files, we should consider it as just a necessary evil. While having SUID or SGID set on certain operating system files is essential to the proper operation of your Linux system, it becomes a security risk when users set SUID or SGID on other files. The problem is that, if intruders find an executable file that belongs to the root user and has the SUID bit set, they can use that to exploit the system. Before they leave, they might leave behind their own root-owned file with SUID set, which will allow them to easily gain entry into the system the next time. If the intruder's SUID file isn't found, the intruder will still have access, even if the original problem is fixed.
The numerical value for SUID is 4000
, and for SGID it's 2000
. To set SUID on a file, you'd just add 4000
to whichever permissions value that you would set otherwise. For example, if you have...
Using extended file attributes to protect sensitive files
Extended file attributes are another tool for helping you to protect sensitive files. They won't keep intruders from accessing your files, but they can help you prevent sensitive files from being altered or deleted. There are quite a few extended attributes, but we only need to look at the ones that deal with file security.
First, let's do an lsattr
command to see which extended attributes you already have set. On the CentOS machine, your output would look something like this:
[donnie@localhost ~]$ lsattr
---------------- ./yum_list.txt
---------------- ./perm_demo.txt
---------------- ./perm_demo_dir
---------------- ./donnie_script.sh
---------------- ./suid_sgid_files.txt
---------------- ./suid_sgid_files2.txt
[donnie@localhost ~]$
So, as yet, I don't have any extended attributes set on any of my files.
On the Ubuntu machine, the output would look more like this:
donnie@ubuntu:~$ lsattr
-------------e-- ./file2.txt
-------------e-...
In this chapter, we reviewed the basics of setting ownership and permissions for files and directories. We then covered what SUID and SGID can do for us when used properly, and the risk of setting them on our own executable files. Finally, we completed this roundup by looking at the two extended file attributes that deal with file security.
In the next chapter, we'll extend what we've learned here to more advanced file and directory access techniques. I'll see you there.