On Tue, Jun 02, 2009 at 09:29:43PM +0800, Zhang Shukun wrote: > thanks! your reply it's very useful to me!! > > yes, it' security purposes! i just trust dom0 , but not trust domU. i want > to save the blocks of improtant files of domU into dom0, when write > operation happend in domU, domU will send the request struct , which contain > the sectors need to write, to dom0, next, in dom0 compare the sector number. > if the sector numbers is which i want to protect, the write operation will > be stoped by dom0. even if intruder get the root privilege in domU, he > can't change the file (for example :files in /bin dir) which i protected. So what I would strongly suggest that you do is to create a userspace program, using the libext2fs library, which reads an unmounted filesystem image, and creates a list of block ranges which should be protected. This program would be run in dom0, and it would then pass the block ranges down a device driver which would restrict write access to the domU guest program. It will be much simpler than trying to figure out this information inside the kernel. Also, note that you need to restrict more information than just actual files; you will also need to disallow changes to certain directories. After all, what use is it to protect the blocks associated with /lib/libc.so.6, if the attacker can simply modify /lib by replacing /lib/libc.so.6 with a new file that has modified contents. And protecting /lib isn't enough, since the attacker could just modify the root directory and replace the /lib directory.... You also have to consider the fact that the attacker could simply modify the inode table and simply change the blocks which a particular file is pointing at. But there are multiple inodes stored in a single block, so if you protect a block in the inode table, that will be effectively preventing multiple inodes in the filesystem from being change, and that might not be desireable depending on what other inodes are sharing a particular block in the inode table with the file you are trying to protect. The bottom line is what you are trying to do is pretty hard; you are trying to write protect part of a filesystem from an untrustworthy root user by restricting write operations on a per-block basis. This is an abstraction violation, and when you violate abstractions, you can expect that (a) things won't be easy, and (b) unless you are very careful, you might not achieve the goal you were hoping for anyway. It might be better, if you really don't trust the domU OS, that you use a fully write protected block device, plus some kind of union filesystem. - Ted _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
