The only other thing you need to know about file system security is that the setuid and setgid flags can be set on an executable permission in order to modify the user account under which the file is executed.
Normally, an executable file inherits its user security context from the user who executes the file. For example, if user “postgres” launches a database executable, that database inherits the UID of user “postgres” in order to access files itself.
But this is a problem for executables that launch automatically at boot time. Daemons and services that launch automatically, will all be launched under the root context because there is no logged-in user during the boot process. This means that every daemon would have full access to the system, and any flaw or poorly coded daemon that a hacker could exploit would provide full access to the system.
The Unix solution to this is the setuid and setgid bits contained in the executable file’s inode. If the setuid flag is set on an executable file, then the executing program (process) inherits its UID from its own file’s UID rather than from the user who started the executable.
This means, for example, that a daemon could have an owner other than root who would only be able to access files that are necessary for the daemon to operate. The setgid flag works the same way, and causes the file to inherit its GID from its file GID rather than the logged-on user’s primary group.
Warning Programs that operate with SetUID or SetGID permissions can open very serious holes in your security. Be extremely cautious about using them.
To create a SetUID executable (also referred to as SUID executables), execute the following command:
setuid bash root
Note that this command will create a shell that always has root permissions—exactly what a hacker would attempt if they could, and what you should never do. If you do this for test purposes, remember to change it back to normal by executing this command:
setuid bash -
You can do the same thing to a file’s group using the setgid command, which gives the executable whatever permissions are held by that group.
SetUID Security Problems
There are numerous security problems associated with SetUID programs; obviously, since they can operate as the root, any exploit that can take control of them and cause them to launch a new process (like a shell) effectively has control of the system.
But there are more subtle ways in which SetUID can cause problems. For example, say a user copies a shell executable to a floppy disk on a system that they have root access to, and uses SetUID to set the shell to load as root. If they can mount this floppy on a system upon which they are a normal unprivileged user, then by running that shell they will have root access. UID 0 on their machine is the same as UID 0 on every other Unix machine, so because the shell program on the floppy has root execution privilege, it can be used to exploit other machines. In many cases, mount is restricted to normal users for this reason. Some newer versions of Unix can be configured to ignore SetUID bits on removable or networked file systems. You should check this exploit specifically on your system to ensure that it doesn’t work.
SetUID Shell scripts
In most versions of Unix, Shell scripts can be marked as SetUID programs and run as the root user. You should avoid doing this to the extent possible, because if the text of a script can be modified by anyone, that user can exploit the script to launch a new shell under the root context. Aside from the obvious method of modifying a script, a user could potentially hook into or replace any executable called by the script (or even modify a program in the
executable’s search path to mimic a normal system executable) to exploit root context. For example, say a shell script that executes as root changes into a user’s directory and then executes a find command. If the user has replaced the find command with another shell script in their own directory, that find command could be executed instead of the system find command and exploited to launch a new shell, modify the user’s permissions, or perform any other action on the system. These sorts of exploits have been used in the past to hack into Unix machines with regularity.
Finding SetUID and SetGID Programs
You should regularly monitor your systems for the presence of SetUID and SetGID programs in order to prevent hackers or users from loading them in and using them as Trojan horses. The methods a potential hacker could use to load a SetUID program onto a system are too numerous to enumerate, but you can avoid them all by using the find command to search for SetUID files.
The following system command (when executed as root) will search for executables with their SetUID or SetGID bits set. By running this regularly and comparing the output with prior output, you can determine when new SetUID programs have been loaded onto your system. find / -type f -perm 4000
Daemons and Daemon Security
When Unix boots, the boot loader loads the kernel without checking permissions of any sort and starts the kernel. The kernel begins checking file system permissions as soon as the file
system is mounted. Once the kernel has loaded, all subsequent processes are loaded in user mode, where their memory is protected from foreign processes by the kernel.
Daemons (services) in Unix are not special applications with a specific service interface like they are in Windows; they are merely executable programs that are launched by a script that is read in at boot time. Daemons launch with the user identity of the user account that owns the executable file system permission.
daemon
A Unix executable that is launched automatically at boot time and normally runs at all times. Similar to a service in Windows.
Many older (and often exploited) daemons require root access to do their work. Sendmail, the standard mail server for Unix, is notorious for its root user context requirements and the many exploits that it has been susceptible to.
Daemons that require root access to operate are almost always examples of lazy programming by programmers or network administrators who don’t want to bother really thinking about how a daemon should be using the system. In every case that I can think of, a more secure alternative exists that operates correctly in the context of a user account that is specifically created for it, and these should be chosen over daemons that require root access. For example, Postfix, a simple alternative to Sendmail, is more secure, easier to configure, and more
feature-rich than Sendmail.
To the extent possible, avoid any software that requires running in the root context. You should also avoid installing software to run as root that does not require it, but allows you to do so anyway. For example, MySQL can be configured with a root user context, but it also runs perfectly fine in its own user context. The more security-minded programmers of PostgreSQL won’t allow it to run in root context and automatically set up a postgres user as part of the normal setup process.
Review Questions
1. Why is Unix security so simple?
2. Why did AT&T originally give UNIX away to anyone who wanted a copy? 3. Why are there so many variations of Unix?
4. In Unix, every system object is represented and controlled by what primary structure?
5. What is the primary security mechanism in Unix? 6. Which component stores permissions?
7. Where is user account information stored on a Unix system? 8. How are permissions handled for the root user in Unix? 9. What is the GID of the wheel or superuser group?
10. What are the basic permissions that can be set for owners, group members, and everyone else in an inode?
11. Which two commands are typically used to modify ownership and permissions on an inode?
12. What does it mean when an executable has its SetUID flag enabled? 13. What makes a daemon different than a normal executable in Unix? Answers
1. Unix was originally designed not to include rigorous security in order to solve problems that didn’t require high level security.
2. AT&T gave UNIX away in the beginning, because their monopoly agreement with the U.S. government prevented them from selling software.
3. AT&T essentially lost control of its development of Unix when they gave it away to Universities in the 1970’s. They also licensed it to numerous hardware developers who modified it as they saw fit. Finally, hackers created their own version using the Internet, and the result is a variety of variations.
4. The file system represents and controls every system object in Unix. 5. File system permissions are the primary security mechanism in Unix. 6. File inodes store permissions in Unix.
7. Unix user account information is stored in the /etc/passwd file. 8. Permissions are not checked for the root user in Unix.
9. The GID of the wheel or superuser group is 0.
10. Read, Write, and Execute are the basic permissions that can be set in an inode. 11. Typically, the chmod and chown commands are used to modify ownership and
permissions on an inode.
12. Having an executable’s SetUID flag enabled means that it runs under the user account context of the file’s owner rather than the logged on user that executes it.
13. Nothing. Daemons are standard executables that run using SetUID permissions.