有一个好的配额策略是很重要的，因为它可以防止用户填满硬盘.

您可以使用两个不同的配额系统: 用户配额和组配额. 就象您所猜到的, 用户配额是指限制用户磁盘空间的占用量, 组配额则是限制组的. 在你设置配额时这一点要记清楚.

在设置配额时有几个需要考虑的关键点:

用户具有完全写权限的每个分区和目录都应该启用配额设置. 结合实用性和安全性, 来计算和分配这些分区和目录的可用配额大小.

那么, 现在您想使用配额了. 首先, 需要检查您是否在内核中启用配额支持. 如果没有, 您需要重新编译内核. 然后, 是否安装了控制 quota 的软件包. 如果没有请安装.

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.

除了通常Unix的权限, ext2 和 ext3 文件系统还提供了一套特别的属性用于控制您的文件和系统. 不同于基本的权限, 这些属性并不能通过 ls -l 命令显示出来, 也不能使用chmod命令修改, 您需要额外的两个工具 lsattr 和 chattr (在e2fsprogs 包中)来管理它们. 注意, 这意味着, 您在备份系统时, 通常不能保存这些属性, 所以, 如果您对它们做了任何修改, 也许可以将其有价值部分 对应的chattr命令写入脚本, 这样就可以在以后必需恢复系统时重新设置.

在所有的属性中, 对于增强安全性最有价值的是参考字符 'i' 和 'a', 它们只能由超级用户设定(或删除):

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 第 10.4.2.1 节 “主动防护”. 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:

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 !

几个月后, 您能肯定硬盘上的 /bin/login 仍然是您安装的那个吗? 如果是一个被黑的版本, 其将输入的密码存储到隐藏的文件中, 或者以明文方式通过邮件发送到网上呢?

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 第 10.2 节 “周期性入侵检测” and 第 4.19 节 “生成系统快照”.

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).

The Debian checksecurity package provides a cron job that runs daily in /etc/cron.daily/checksecurity^[30]. 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.