lkml.org 
[lkml]   [2009]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3] vfs: new O_NODE open flag
From
Date
On Mon, 7 Dec 2009, Alan Cox wrote:
> > > First obvious attack: get an O_NODE handle to a device you have assigned
> > > to your ownership
> > >
> > > while(1)
> > > fchmod(fd, 0666);
> > >
> > > wait for device to unload, reload and be intended for another user
> > > Race udev to a real open. You have a similar problem with vhangup() and
> > > ttys.
> >
> > If this was a udev device, the same attack is possible with a hard
> > link to the device. Except the attacker simply does link() instad of
> > open(O_NODE) and chmod() instead of fchmod().
>
> If your distribution does not use a separate tmpfs for devices then yes -
> but that's old news - and also needs revoke() to fix.

How does revoke() fix the hard link attack? It revokes file
descriptors, doesn't it?

> It's a requirement
> of udev as it stands that it runs on its own file system and I would hope
> that all distributions using udev get this right.

Not the one I'm running.

> With O_NODE I don't
> need to make the hardlink and all the "same as a hardlink" justifications
> come crashing down.

Well, yes. That's true. But I still don't think revoke() is the
answer here. For example even without the possibility of hard links
there's still a race in udev in the following course of events:

open("/dev/foo", O_RDWR)
... open passes permission checks
... driver gets unloaded
... driver intended for other user gets loaded
... open finds new driver

revoke() isn't going to help there, there's no open file descriptor
yet, it's only in the making.

What we really need is to revoke the *inode*, so that it cannot be
opened any more. Doing it with unlink() and revoke() and requiring
that link() does not work on the filesystem is a poor and racy
substitute for that.

Miklos


\
 
 \ /
  Last update: 2009-12-07 16:13    [W:0.045 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site