Re: Names vs. Inodes

gregat_private

On Fri, Jul 20, 2001 at 10:46:43PM -0700, Crispin Cowan wrote:
> 
> SubDomain only allows the creation of hard & soft links by confined processes if such
> permission is specified.  But the links may exist anyway, and the permission may be
> granted.

But since SubDomain is running in a "controlled" environment (you know
the whole layout of the file system, as you created the distro in the
first place) is this a real problem?

> > So the inode that is passed to permission() should only have a dentry
> > list containing 1 dentry.  Reconstruct the path from that dentry, and
> > bob's your uncle.
> 
> I also thought of this.  It's appealing, and in the common case, it will work.
> Unfortunately, it leaves a DoS hole (observation due to Chris).  Someone with an
> unconfined, or appropriately loosely confined, process can create thousands of hard
> links to a file they don't own.  The result is that the SubDomain module spends a gross
> amount of time inside the kernel reconstructing each of many alias paths to a file that
> a confined process is trying to access.
> 
> If it was just a mild performance issue, I wouldn't worry about it.  But this is a big
> DoS issue.

But yesterday you said in regards to my worry of "hostile" processes
calling mount:

On Thu, Jul 19, 2001 at 10:15:33PM -0700, Crispin Cowan wrote:
> 
> SubDomain does not allow confined programs to call mount or umount.  SubDomain's
> threat model is only concerned with confined processes and principals external to
> the machine.  Unconfined processes don't matter, because there either shouldn't be
> any, or they are there for a reason and are trusted.
> 

Shouldn't that same statement work for processes calling link?
Since you trust the system enough to not worry about mount, what is the
difference?  You can prevent loosely confined processes from creating
lots of linked files.  And you said you don't care about unconfined
processes, as they are trusted (if there at all.)

And secondly, have you tried measuring the performance if this happens?
How long does it really take to do the reconstruction for thousands of
dentrys?

Shouldn't you just stop the dentry path reconstruction on the first
failed dentry?  That would prevent you from having to go through all of
them.  Also a simple "hey, I'm reconstructing the 10th dentry for this
inode, something is not right here" check should prevent you from taking
up lots of kernel time.

thanks,

greg k-h

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