Dear Ted, Thank you very much for your patient answer. you always Shine a light on me for some new idea. i have tested in domU for protect file writen, but failed. the reason is that each time when i open a file for writting, and save back to the disk. the block number of the file will change. (i use filefrag to see the blocks of a file). but success from a file for reading, by first get the block number of the file and then save the block number to dom0, each time when the file is read in domU, it will send request to dom0. if i detect the block number is the same to which i saved before, the read operation will be stopped. is that the filesystem mechanism to change bock number of a file when written even if the operation is to make the file to smaller than before? and how could i make the file written protection in the block level when the block number always change? Thanks a lot ;) <div class="gmail_quote">2009/6/4 Theodore Tso <<a href="mailto:tytso@mit.edu">tytso@mit.edu</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">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. </div>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 </blockquote></div> -- Regards, Sucan