Re: Names vs. Inodes

crispinat_private

Greg KH wrote:

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

Yes, on both counts:

   * You don't necessarily control the whole file system. SubDomain can be used to just
     confine programs you don't trust, but need secured. For instance, you might run BIND
     and Sendmail in SubDomain confinement, but leave the rest of your workstation
     unconfined.
   * Some applications make real use of hard links, e.g. the Courier MTA uses hard links to
     to manage mail spools.

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

Yes, I did.  Hmmm ... :-)  The main difference appears to be that a completely unprivileged
but unconfined shell (e.g. a nobody shell) can perpetrate the "many hard links" attack,
where as you need root to call mount.  It is reasonable to think that you can SubDomain
confine all the root processes on a machine, but somewhat less likely that you can confine
all processes on the machine.

It's a subtle distinction, but basically I am not concerned about rogue root shells, because
they should not exist. I don't *want* to have to be concerned about rogue nobody shells,
because it is very difficult to ensure that they never exist.

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

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