よい quota ポリシーを持つことは重要です。なぜならそれはユーザがハード ディスクをいっぱいにするのを防ぐからです。
2 種類の異なる quota システムを使うことができます: ユーザ quota とグループ quota です。ご想像のとおり、ユーザ quota はユーザが占めることができる スペースの量を制限し、グループ quota は同じことをグループに対して行います。 quota の大きさを決めるときにはこれに注意してください。
quota システムを設定するときに考えるべき重要な点がいくつかあります:
quota を十分に小さくして、ユーザがディスクスペースを食いつくさない ようにしましょう。
quota を十分に大きくして、ユーザが文句を言ったりメール quota の せいでユーザが長期間メールを受けとれなくなったりしないようにしましょう。
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.
それで、quota を使いたいわけです。最初にあなたのカーネルで quota サポートが 有効になっているか調べる必要があります。もしそうなっていないなら、カーネルを 再コンパイルする必要があるでしょう。 そのあとで、「quota」パッケージがインストールされているか制御してください。 もしインストールされていないならこれも必要です。
それぞれのファイルシステムで quota を有効にするのは簡単で、ファイル
/etc/fstab 中の
defaults という設定を
defaults,usrquota に変更するだけです。グループ quota が必要なら、
usrquota を
grpquota に置きかえてください。両方を使うことも できます。そして quota を使いたいファイルシステムのルートに空の quota.user および quota.group というファイルを作成してください (たとえば、 /home ファイルシステムでは
touch /home/quota.user /home/quota.group とするわけです)。
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.
quota についてくわしくは quota のマニュアルページや quota mini-howto (/usr/share/doc/HOWTO/en-html/mini/Quota.html)をごらんください。
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
「事前の対策」. 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;
Add the command
lcap CAP_LINUX_IMMUTABLE (as well as
lcap CAP_SYS_MODULE, as suggested in
「事前の対策」) to one of the startup scripts;
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. ファイルシステムの完全性を確かめる
あなたのハードドライブにある /bin/login は本当に数か月前にインストールした バイナリと同じですか? もしそれが入力されたパスワードを隠しファイルに 保存したり平文でインターネットじゅうにメールで送る、ハックされたバージョンなら どうでしょうか?
保護のためのただひとつの方法はそのファイルの実際の md5sum と古い md5sum を 比較して毎時間 (または毎日、または毎月) (私は毎日がすきです) ファイルを 調べることです。異なる 2 個のファイルが同じ md5sum を持つことはありえません (MD5 ダイジェストは 128 ビットです。よって 2 個の異なるファイルが同じ md5sum を持つ確率はおよそ 3.4e3803 にひとつです)。よって、 だれかがそのマシンで md5sum を作るアルゴリズムをハックしたのでないかぎり、 あなたは安全な場所にいることになります。これは、まあ、とても困難で、まず ありえないでしょう。このバイナリの監査は非常に重要だと 本当に考えるべきです。なぜならこれはバイナリへの変更を認識する簡単な 方法だからです。これに使われる一般的な道具は sXid、 AIDE (Advanced Intrusion Detection Environment)、TripWire (non-freeです。新バージョンは GPL になる予定です)、 integrit そして samhainです。
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
「Do periodic integrity checks」 and
「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).
