As we’ve already established, the best policy is to only grant users the specific access to the system and its contents that they absolutely need. Next, you need to identify all files on the system that could possibly be accessed or modified by unintended users and used to the detriment of the confidentiality, integrity, or security of the system and its contents.
You should consider several items. First, identify all files that are world writable, which could potentially pose a risk to the confidentiality, integrity, or security of the system or its data, if modified.
World-Writable Files The following command will review the file system and identify world-writable files and directories, which malicious users could modify and possibly use to escalate their privileges on the system. For the sake of brevity in this example, the command is limited to the contents of the /tmp folder, but you could choose any folder, even the /(root) directory itself:
Compare the previous output to the following ls output and notice that it successfully identifies the world-writable files, while ignoring the owner-writable file with more restrictive permissions:
linux:/tmp # ls -al total 0
drwxrwxrwt 4 root root 140 Mar 3 09:59 ./
drwxr-xr-x 10 root root 220 Mar 3 09:54 ../
drwxrwxrwt 2 root root 60 Mar 3 09:55 .ICE-unix/
drwxrwxrwt 2 root root 60 Mar 3 09:55 .X11-unix/
-rwx--- 1 root root 0 Mar 3 09:59 owner_writable*
-rwxrwxrwx 1 root root 0 Mar 3 09:59 world_writable*
World-Executable Files Just as you must identify files that are world-writable, you must also enumerate all binaries on a system that can be executed by a restricted user account and possibly used to escalate the permissions of the restricted account either directly or indirectly. The following command will enumerate all binaries in the /bin directory that can be executed by any user on the system:
linux:/bin # find /bin -perm -o=x
Chapter 4: Local Access Control
67
Although this may not seem to pose an immediate threat, combining world-writable files and folders with utilities such as tftp, Netcat, or others can lead to attackers using the limited access provided to them to upload the resources to the system that are necessary for them to gain root access.
SetUID/SUID/SGID Bits In certain distributions and installations of Linux, SetUID/SUID/
SGID bits are set to allow a binary to run with root permissions and reliably function on the system. This ensures the binaries never encounter any permissions issues while accomplishing their specific tasks, as they have full access to system resources. It also provides the ultimate in accessibility for legitimate users and attackers alike.
Despite being a bad idea from the start and having been written about extensively, you still commonly see this configuration today. You certainly need to audit this item, especially with the increased attention that process and driver vulnerabilities are being given in today’s exploits. As part of performing a security audit of any system, searching for anything with SetUID/SUID/SGID bits set is essential. Use the following two commands to perform this search:
SetUID/SUID:
find / -type f -perm 04000 -ls SGID:
find / -type f -perm 02000 –ls
Once you’ve identified binaries that have SetUID/SUID/SGID bits set, you can remove them with the following commands. Be very careful, however! Make sure you test the system fully after making modifications such as these, as they can have far-reaching effects:
SetUID/SUID:
chmod –R u-s /var/directory/
chmod u-s /usr/bin/file SGID:
chmod –R g-s /var/directory/
chmod g-s /usr/bin/file
Restrict Ability to Make System Changes One of the best security enhancements for a Linux environment is to restrict or eliminate the ability to make any changes to it. After a Linux box is completely set up, dialed in, and hardened, start eliminating anything that can be used to alter, debug, or reverse engineer it. After properly planning and testing file permissions and attributes, identify all files that absolutely do not need to change, such as critical system files (or any other file that must not change), and make them immutable.
Immutable files are files with the immutable flag set (using the chattr command), and these files cannot be modified or deleted, even by root, unless the flag is removed.
Set the immutable flag as follows:
chattr +i /var/test_file
The immutable attribute can be identified using the lsattr command. If the immutable flag is set, the output will contain an i in the listing:
lsattr test_file
----i--- test_file
Next, remove the compiler. If the intent of a particular box is to be completely hardened and to function without being modified for a significant period of time, there is no reason to leave a development environment installed, as it will likely only be used for no good. If attackers happen to get some level of access on the box, you don’t want to give them anything that makes their job any easier.
On the same note, once the hardware is installed and working properly, the box does not need to have loadable kernel module support enabled. In a stable system that has no need of any hardware upgrades or module updates, this functionality will likely be used to reduce security, not increase it. Installing a rootkit is a good example of reducing security.
Remove write access from all static files and set the immutable flag on unchanging system files and utilities. Take care not to remove write access to logs or other dynamic files. If access is needed later, you can always grant it using root permissions.
Finally, eliminate as many debugging or reverse engineering utilities as possible.
They can all be used for illegitimate purposes by attackers. Particularly, if the box is physically accessible, you do not need to have them installed since they can be run from CD in a statically compiled or self-contained CD environment.