Re: Names vs. Inodes

gregat_private

On Thu, Jul 19, 2001 at 12:19:14PM -0700, Crispin Cowan wrote:
> 
> If you think of it from the perspective of protecting a file, then you're
> right, it makes no sense: you need to block all the possible ways to get to the
> file.
> 
> However, we're doing the *dual* of that.  SubDomain doesn't protect files, it
> confines processes, rather similar to chroot.  In SubDomain, you specify the
> names of all the files that a give program may access.  When that program
> executes, it is instantiated as a process confined by a profile that prescribes
> the set of named files the process can access.
> 
> Every time the process calls open, SubDomain resolves the call into a name, and
> checks to see if the name is on the "allowed" list.  If it's not on the list,
> the access is denied.

Ah, but most SubDomain profiles contain:
	/tmp/*		rw

Which allows them to read and write to the /tmp directory.

So I, as a malicious user do the following:
	umount /tmp
	mount /dev/sda3 /tmp

where /dev/sda3 is the /etc partition.

Now my protected program can read and write to the /tmp/shadow file if
it gains root permissions.

If you are checking the inode of the /tmp/shadow file, and see that it
contains 2 dentry structures that resolve to /etc/shadow and
/tmp/shadow, you should probably not allow access to the file,
even though it passes one of the rules in the SubDomain profile.  If you
just relied on the original access by the /tmp path, SubDomain would
have allowed access.

What I'm trying to get at here, is that for 2.4.x and on, pure file path name
based systems are going to have to care about the inode of the existing
file that permission() is being called for within their code.  They
don't have to change their security model as it's seen by the outside
world (like the profiles for SubDomain and LIDS), but their internal
code will have to change to handle the fact that the internal kernel
code has changed.

thanks,

greg k-h

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