linux-kernel - Re: [PATCH v3] vfs: new O

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 07 Dec 2009 16:11:04 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	miklos@...redi.hu, miklos@...redi.hu, luto@....edu,
	akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] vfs: new O_NODE open flag

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/