如何保障Linux系统的临时文件安全？

如何保障Linux系统的临时文件安全？

在一个典型的Linux系统中，至少有两个目录或分区保持着临时文件。其中之一是/tmp目录，再者是/var/tmp。在更新的Linux内核的系统中，还可能有/dev/shm，它是用tmpfs文件系统装载的。 存储临时文件的目录存在着一个问题，即这些目录可以成为损害系统安全的僵尸和rootkit的温床。这是因为在多数情况下，任何人（或任何过程）都可以向这些目录写入东西，还有不安全的许可问题。我们知道都sticky bit，该位可以理解为防删除位。如果希望用户能够添加文件但同时不能删除文件, 则可以对文件使用sticky bit位。设置该位后, 就算用户对目录具有写权限, 也不能删除该文件。多数Linux发行版本在临时目录上设置sticky位，这意味着用户A不能清除属于用户B的一个文件，反之亦然。但是，根据文件自身的许可，用户A有可能查看并修改那个文件的内容。 一个典型的Linux安装将/tmp设置为mode 1777，这意味着它设置了sticky位，并且可被所有的用户读取、写入、执行。多数情况下，这如同其设置的安全一样，主要是因为/tmp目录仅仅是一个目录，而不是一个自己的文件系统。/tmp目录依赖于/分区，这样一来它也就必须遵循其装载选项。 一个更加安全的解决方案可能是将/tmp设置在其自己的分区上，这样一来它就可以独立于/分区装载，并且可以拥有更多的限制选项。/tmp分区的/etc/fstab项目的一个例子看起来是这样的： /dev/sda7 /tmp ext3 nosuid,noexec,nodev,rw 0 0 这就设置了nosuid、noexec、nodev选项，意味着不允许任何suid程序，从这个分区不能执行任何内容，并且不存在设备文件。 你可以清除/var/tmp目录，并创建一个symlink指向/tmp目录，如此一来，/var/tmp中的临时文件就可以利用这些限制性的装载选项。 /dev/shm虚拟文件系统也需要保障其安全，这可以通过改变/etc/fstab而实现。典型情况下，/dev/shm通过defaults选项加载，对保证其安全性是很不够的。就像/tmp的fstab一样，它应当具备限制性更强的加载选项： none /dev/shm tmpfs defaults,nosuid,noexec,rw 0 0 最后，如果你没有能力在现有的驱动器上创建一个最新的/tmp分区，你可以通过创建一个loopback文件系统来利用Linux内核的loopback特性，这个文件系统可被装载为/tmp，并可以使用相同的限制加载选项。要创建一个1GB的loopback文件系统，需要执行： # dd if=/dev/zero of=/.tmpfs bs=1024 count=1000000# mke2fs -j /.tmpfs# cp -av /tmp /tmp.old# mount -o loop,noexec,nosuid,rw /.tmpfs /tmp# chmod 1777 /tmp# mv -f /tmp.old/* /tmp/# rmdir /tmp.old 一旦完成，需要编辑/etc/fstab，以便于在启动时自动加载loopback文件系统： /.tmpfs /tmp ext3 loop,nosuid,noexec,rw 0 0 保障恰当的许可和使用限制性加裁选项等方法能够防止对系统的许多损害。如果一个僵尸在一个不能执行的文件系统上安了家，那么它从本质上讲也是不值得担心的。