Files and File system Security

and File system Security
A few minutes of preparation and planning ahead before putting your systems online
can help to protect them and the data stored on them.
• There should never be a reason for users’ home directories to allow SUID/SGID
programs to be run from there. Use the nosuid option in /etc/fstab for partitions
that are writable by others than root. You may also wish to use nodev and noexec
on users’ home partitions, as well as /var, thus prohibiting execution of programs,
and creation of character or block devices, which should never be necessary anyway.

• If you are exporting file-systems using NFS, be sure to configure /etc/exports
with the most restrictive access possible. This means not using wild cards, not allowing
root write access, and exporting read-only wherever possible.
• Configure your users’ file-creation umask to be as restrictive as possible. See the
Section called Umask Settings.
• If you are mounting file systems using a network file system such as NFS, be sure
to configure /etc/exports with suitable restrictions. Typically, using ‘nodev’, ‘nosuid’,
and perhaps ‘noexec’, are desirable.
• Set file system limits instead of allowing unlimited as is the default. You
can control the per-user limits using the resource-limits PAM module and
/etc/pam.d/limits.conf. For example, limits for group users might look like
this:
@users hard core 0
@users hard nproc 50
@users hard rss 5000
This says to prohibit the creation of core files, restrict the number of processes to
50, and restrict memory usage per user to 5M.
You can also use the /etc/login.defs configuration file to set the same limits.
• The /var/log/wtmp and /var/run/utmp files contain the login records for all users
on your system. Their integrity must be maintained because they can be used to
determine when and from where a user (or potential intruder) has entered your
system. These files should also have 644 permissions, without affecting normal
system operation.
• The immutable bit can be used to prevent accidentally deleting or overwriting a
file that must be protected. It also prevents someone from creating a hard link to
the file. See the chattr(1) man page for information on the immutable bit.
• SUID and SGID files on your system are a potential security risk, and should be
monitored closely. Because these programs grant special privileges to the user who
is executing them, it is necessary to ensure that insecure programs are not installed.
A favorite trick of crackers is to exploit SUID-root programs, then leave a SUID
program as a back door to get in the next time, even if the original hole is plugged.
Find all SUID/SGID programs on your system, and keep track of what they are,
so you are aware of any changes which could indicate a potential intruder. Use the
following command to find all SUID/SGID programs on your system:
root# find / -type f \( -perm -04000 -o -perm -02000 \)
The Debian distribution runs a job each night to determine what SUID files exist. It
then compares this to the previous night’s run. You can look in /var/log/setuid*
for this log.
You can remove the SUID or SGID permissions on a suspicious program with
chmod, then restore them back if you absolutely feel it is necessary.
• World-writable files, particularly system files, can be a security hole if a cracker
gains access to your system and modifies them. Additionally, world-writable directories
are dangerous, since they allow a cracker to add or delete files as he wishes.
To locate all world-writable files on your system, use the following command:
root# find / -perm -2 ! -type l -ls
and be sure you know why those files are writable. In the normal course of operation,
several files will be world-writable, including some from /dev, and symbolic
links, thus the ! -type l which excludes these from the previous find command.
•
Unowned files may also be an indication an intruder has accessed your system.
You can locate files on your system that have no owner, or belong to no group with
the command:
root# find / \( -nouser -o -nogroup \) -print
• Finding .rhosts files should be a part of your regular system administration duties,
as these files should not be permitted on your system. Remember, a cracker
only needs one insecure account to potentially gain access to your entire network.
You can locate all .rhosts files on your system with the following command:
root# find /home -name .rhosts -print
•
Finally, before changing permissions on any system files, make sure you understand
what you are doing. Never change permissions on a file because it seems
like the easy way to get things working. Always determine why the file has that
permission before changing it.