what's relationship between VFS inode and ext3_inode?

[Sucan Zhang]

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 ;)

2009/6/4 Theodore Tso <tytso at mit.edu>

> 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
>



-- 
Regards,
Sucan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20090610/a1571cdb/attachment.htm>