what's relationship between VFS inode and ext3_inode?

[Theodore Tso]

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