Re: Kernel Security Extensions USENIX BOF Summary

Previous message: Crispin Cowan: "Re: Hooks, authority, MAC, the future and proposol"
In reply to: Greg KH: "Re: Kernel Security Extensions USENIX BOF Summary"
Next in thread: Crispin Cowan: "Re: Kernel Security Extensions USENIX BOF Summary"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

aoat_private

On Don, 05 Jul 2001 Greg KH wrote:
> On Thu, Jul 05, 2001 at 05:07:49PM -0400, jmjonesat_private wrote:
> > 
> > Only one question: what if you WANT to reconstruct pathname data... not
> > just absolute, but also what was originally specified.  Is that
> > possible with strictly inode-based protections, and, if not, is there a 
> > SIMPLE way to add it to the LSM model without getting into "mixed models"?
> 
> An inode can point to any number of valid paths to that file.  Think of
> multiple mounts of a filesystem at different places in the tree.
> (Hm, let's mount /dev/hdd8 at /etc, /tmp/etc, /var/etc, and
> /home/foo/etc )
> So reconstruction the original path from a inode is almost impossible.
> 
> Also remember per-user namespaces :)

Then we must come up with a clear strategy how to deal with it. There are
several solutions:
- Provide the path the process used for lookup, turned into an absolute path
(context solution)
- Return the path via first mount
- ?

We might have to have a per-process table of mount parents as soon as we come
to multiple mounts, what is sure ugly.   

> Did that answer your question?

No, it only details the problem...

Amon.

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module