Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Configuring the File System
The default file permissions on some files might not be adequate in all situations; therefore, configure the Sun Linux file system to provide additional protection. Also, several mount options are available to increase security, when used effectively. Sun Linux systems need some adjustment to prevent attackers from gaining superuser privileges.
This section contains the following topics:
- "Review set-user-ID and set-group-ID Files"
- "Review World-Writable File System Objects"
- "Review Unowned File System Objects"
Review set-user-ID and set-group-ID Files
The set-user-ID and set-group-ID bits (often referred to as SUID and SGID bits) on an executable file indicate to a system that the executable should operate with the privileges of the file's owner or group. For example, the effective user ID of the running program becomes that of the executable's owner, in the set-user-ID instance. Similarly, a set-group-ID file sets the running program's effective group ID to the executable's group. If the command with the set-user-ID and/or set-group-ID bit set is written correctly with security in mind, it can be a useful method for solving some tricky operational challenges. These operational challenges can often be solved using forms of role-based access control, such as sudo. For more information on sudo, see "Limit Root Access" on page 25."
Many set-user-ID and set-group-ID commands have had flaws. Attackers have used these flaws to successfully exploit systems. When security problems are reported, Sun fixes them and provides a patch.
Attackers might use the set-user-ID or set-group-ID commands to create backdoors. One way they do this is by copying a system shell to a hidden location and adding the set-user-ID bit. This technique allows attackers to execute shells to gain elevated privileges (most often superuser).
To Find All set-user-ID and set-group-ID Files
To find all the set-user-ID and set-group-ID files on a server, use the following command:
# find / -type f \( -perm -u+s -o -perm -g+s \) –ls
Store the output to a file on another system.
Compare the output against the current file system from time to time, especially after applying patches, to find any unwanted additions.
Review World-Writable File System Objects
A world-writable object is one that has the world-write permission bit set. World-writable objects are problematic because any user can modify the object. An attacker might use a world-writable file to perform a disk space-based denial of service attack on a system, or an attacker might modify the object, violating its integrity. We recommend that all world-writable objects be catalogued and tracked over a system's lifecycle. Objects that do not require this setting should have their permissions reset to a stronger value.
To Find World-Writable File System Objects
To find all of the world-writable files and directories on a system, use the following command.
# find / \(-type f -o -type d \)-perm -0002 –ls
NOTE
All world-writable directories should be configured with the "sticky" bit to prevent users from deleting files owned by other users. For more information on this capability, refer to the chmod(1) manual page.
Review Unowned File System Objects
Typically, file system objects stored on a system can be directly attributed to a user and group that exists either on the system or in a naming service (for example, LDAP) used by the system. It is possible for a user or group to be removed from a system, leaving file system objects in an unowned state. That is, the files and directories are now owned by a user or group that no longer exists on the system.
This situation can also occur when extracting archives (for example, tar) built on a different system. These programs can be configured to preserve the original object's ownership and permissions of the archived objects. These programs restore the settings without regard to whether the user or group assigned to the object actually exists on the new system.
To Find Unowned File System Objects
To find all file system objects that are not owned by a valid user on a system, use the command:
# find / -nouser –ls
To find all file system objects that are not owned by a valid group on a system, use the following command:
# find / -nogroup –ls
NOTE
In general, all file system objects on a system should be assigned to a valid user and group. Be sure to assign a valid user or group to any files found using the previous commands.