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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 7 Dec 2009 14:46:23 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	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

> > 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. 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. With O_NODE I don't
need to make the hardlink and all the "same as a hardlink" justifications
come crashing down.

This always comes back to the same thing - you need revoke() on device
files. The general case revoke is much more questionable (and indeed
almost every Unixen with revoke does not support revoke of files)

So we are back where we started - a prerequisite for O_NODE is revoke()
at least for device files and possibly for O_NODE opens on normal files.
O_NODE isn't per-se the problem, the problem is the lack of revoke() - it
just gets caught up in the fallout along with many other things including
all sorts of stuff the GUI folks want to do but cannot currently provide.

Alan
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ