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 ;)
2009/6/4 Theodore Tso <tytso@xxxxxxx>
On Tue, Jun 02, 2009 at 09:29:43PM +0800, Zhang Shukun wrote:So what I would strongly suggest that you do is to create a userspace
> 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.
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
--
Regards,
Sucan
_______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
