4.17. File system limits and control
Having a good quota policy is important, as it keeps users from filling up the hard disk(s).
You can use two different quota systems: user quota and group quota. As you probably figured out, user quota limits the amount of space a user can take up, group quota does the equivalent for groups. Keep this in mind when you're working out quota sizes.
There are a few important points to think about in setting up a quota system:
Keep the quotas small enough, so users do not eat up your disk space.
Keep the quotas big enough, so users do not complain or their mail quota keeps them from accepting mail over a longer period.
Use quotas on all user-writable areas, on /home
as well as on /tmp
.
Every partition or directory to which users have full write access should be quota enabled. Calculate and assign a workable quota size for those partitions and directories which combines usability and security.
So, now you want to use quotas. First of all you need to check whether you enabled quota support in your kernel. If not, you will need to recompile it. After this, control whether the package quota is installed. If not you will need this one as well.
Enabling quota for the respective file systems is as easy as modifying the
defaults
setting to
defaults,usrquota
in your
/etc/fstab
file. If you need group quota, substitute
usrquota
to
grpquota
. You can also use them both. Then create empty quota.user and quota.group files in the roots of the file systems you want to use quotas on (e.g.
touch
/home/quota.user /home/quota.group
for a
/home
file system).
Restart
quota
by doing
/etc/init.d/quota stop;/etc/init.d/quota
start
. Now quota should be running, and quota sizes can be set.
Editing quotas for a specific user can be done by
edquota -u <user>
. Group quotas can be modified with
edquota -g <group>
. Then set the soft and hard quota and/or inode quotas as needed.
For more information about quotas, read the quota man page, and the quota mini-howto (/usr/share/doc/HOWTO/en-html/mini/Quota.html
). You may also want to look at pam_limits.so
.
4.17.2. The ext2 filesystem specific attributes (chattr
/lsattr
)
In addition to the usual Unix permissions, the ext2 and ext3 filesystems offer a set of specific attributes that give you more control over the files on your system. Unlike the basic permissions, these attributes are not displayed by the usual ls -l
command or changed using chmod
, and you need two other utilities, lsattr
and chattr
(in package e2fsprogs) to manage them. Note that this means that these attributes will usually not be saved when you backup your system, so if you change any of them, it may be worth saving the successive chattr
commands in a script so that you can set them again later if you have to restore a backup.
Among all available attributes, the two that are most important for increasing security are referenced by the letters 'i' and 'a', and they can only be set (or removed) by the superuser:
The 'i' attribute ('immutable'): a file with this attribute can neither be modified nor deleted or renamed and no link can be created to it, even by the superuser.
The 'a' attribute ('append'): this attribute has the same effect that the immutable attribute, except that you can still open the file in append mode. This means that you can still add more content to it but it is impossible to modify previous content. This attribute is especially useful for the log files stored in /var/log/
, though you should consider that they get moved sometimes due to the log rotation scripts.
These attributes can also be set for directories, in which case everyone is denied the right to modify the contents of a directory list (e.g. rename or remove a file, ...). When applied to a directory, the append attribute only allows file creation.
It is easy to see how the 'a' attribute improves security, by giving to programs that are not running as the superuser the ability to add data to a file without modifying its previous content. On the other hand, the 'i' attribute seems less interesting: after all, the superuser can already use the basic Unix permissions to restrict access to a file, and an intruder that would get access to the superuser account could always use the chattr
program to remove the attribute. Such an intruder may first be confused when noticing not being able to remove a file, but you should not assume blindness - after all, the intruder got into your system! Some manuals (including a previous version of this document) suggest to simply remove the chattr
and lsattr
programs from the system to increase security, but this kind of strategy, also known as "security by obscurity", is to be absolutely avoided, since it provides a false sense of security.
A secure way to solve this problem is to use the capabilities of the Linux kernel, as described in
Section 10.4.2.1, “Proactive defense”. The capability of interest here is called
CAP_LINUX_IMMUTABLE
: if you remove it from the capabilities bounding set (using for example the command
lcap CAP_LINUX_IMMUTABLE
) it won't be possible to change any 'a' or 'i' attribute on your system anymore, even by the superuser ! A complete strategy could be as follows:
Set the attributes 'a' and 'i' on any file you want;
Set the 'i' attribute on this script and other startup files, as well as on the lcap
binary itself;
Execute the above command manually (or reboot your system to make sure everything works as planned).
Now that the capability has been removed from the system, an intruder cannot change any attribute on the protected files, and thus cannot change or remove the files. If the machine is forced to reboot (which is the only way to restore the capabilities bounding set), it will easily be detected, and the capability will be removed again as soon as the system restarts anyway. The only way to change a protected file would be to boot the system in single-user mode or using another bootdisk, two operations that require physical access to the machine !
4.17.3. Checking file system integrity
Are you sure /bin/login
on your hard drive is still the binary you installed there some months ago? What if it is a hacked version, which stores the entered password in a hidden file or mails it in clear-text version all over the Internet?
The only method to have some kind of protection is to check your files every hour/day/month (I prefer daily) by comparing the actual and the old md5sum of this file. Two files cannot have the same md5sum (the MD5 digest is 128 bits, so the chance that two different files will have the same md5sum is roughly one in 3.4e3803), so you're on the safe site here, unless someone has also hacked the algorithm that creates md5sums on that machine. This is, well, extremely difficult and very unlikely. You really should consider this auditing of your binaries as very important, since it is an easy way to recognize changes at your binaries.
Common tools used for this are
sxid,
aide (Advanced Intrusion Detection Environment),
tripwire,
integrit and
samhain. Installing
debsums
will also help you to check the file system integrity, by comparing the md5sums of every file against the md5sums used in the Debian package archive. But beware: those files can easily be changed by an attacker and not all packages provide md5sums listings for the binaries they provided. For more information please read
Section 10.2, “Do periodic integrity checks” and
Section 4.19, “Taking a snapshot of the system”.
You might want to use locate
to index the whole filesystem, if so, consider the implications of that. The Debian findutils package contains locate
which runs as user nobody, and so it only indexes files which are visible to everybody. However, if you change it's behaviour you will make all file locations visible to all users. If you want to index all the filesystem (not the bits that the user nobody can see) you can replace locate
with the package slocate. slocate is labeled as a security enhanced version of GNU locate, but it actually provides additional file-locating functionality. When using slocate
, the user only sees the actually accessible files and you can exclude any files or directories on the system. The slocate package runs its update process with higher privledges than locate, and indexes every file. Users are then able to quickly search for every file which they are able to see. slocate
doesn't let them see new files; it filters the output based on your UID.
You might want to use bsign or elfsign. elfsign provides an utility to add a digital signature to an ELF binary and a second utility to verify that signature. The current implementation uses PKI to sign the checksum of the binary. The benefits of doing this are that it enables one to determine if a binary has been modified and who created it. bsign uses GPG, elfsign uses PKI (X.509) certificates (OpenSSL).
4.17.4. Setting up setuid check
The Debian
checksecurity package provides a
cron
job that runs daily in
/etc/cron.daily/checksecurity
. This
cron
job will run the
/usr/sbin/checksecurity
script that will store information of this changes.
The default behavior does not send this information to the superuser but, instead keeps daily copies of the changes in /var/log/setuid.changes
. You should set the MAILTO variable (in /etc/checksecurity.conf
) to 'root' to have this information mailed to the superuser. See checksecurity(8) manual page for more configuration info.