From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lutomirski Subject: Re: [PATCH v3] vfs: new O_NODE open flag Date: Mon, 7 Dec 2009 10:03:33 -0500 Message-ID: References: <20091207122346.6d18a8e1@lxorguk.ukuu.org.uk> <20091207130339.620b904b@lxorguk.ukuu.org.uk> <20091207131546.2af06647@lxorguk.ukuu.org.uk> <20091207141321.0964461d@lxorguk.ukuu.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Miklos Szeredi , akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Alan Cox Return-path: Received: from mail-fx0-f213.google.com ([209.85.220.213]:33203 "EHLO mail-fx0-f213.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932508AbZLGPDr convert rfc822-to-8bit (ORCPT ); Mon, 7 Dec 2009 10:03:47 -0500 In-Reply-To: <20091207141321.0964461d@lxorguk.ukuu.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Dec 7, 2009 at 9:13 AM, Alan Cox wro= te: >> > That is *exactly* the problem, which is clearly what you are missi= ng here. >> >> I don't think so, but maybe I'm wrong. =A0Could you describe your at= tack >> scenario in detail then, please? > > First obvious attack: get an O_NODE handle to a device you have assig= ned > to your ownership > > =A0 =A0 =A0 =A0while(1) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fchmod(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() a= nd > ttys. Huh? I would've thought that udev would (and already does?), on device unload, chown to 0:0, then chmod to 0000, then unlink, in which case that attack doesn't work. If you mean that someone could have an O_NODE handle open, then the device unregisters, then, before udev has a chance to do anything at all, a new device w/ the same major/minor numbers appears, then the O_NODE handle owner upgrades to a real fd, then we have worse worries: the attacker could just open the device node on disk without O_NODE, hard links, or any other funny tricks. revoke() wouldn't fix that either. I'll admit that O_NODE scares me a bit from a security perspective, but so do hard links and /proc/self/fd in general, and I'm not really convinced that there are any new attacks here. Would you be okay with a patch that prevented opening /proc/self/fd/xxx on O_NODE handles? I personally don't care about O_NODE all that much, but I'd like a decent in-kernel AFS implementation (and a decent revoke() implementation, and especially the ability to revoke whole filesystems would be really nice too). --Andy > > This cannot happen with the existing kernel because there cannot be a= n > open handle when the original device unload occurs[1] and it cannot h= appen > with vhangup because the hangup is basically a special case revoke() > implementation for tty devices. > > O_NODE changes the whole lifetime semantics for inodes. It's not > something you can do casually. pioctl() gets this right although for = the > same reason as path based chmod/chown/etc all get it right, O_NODE br= eaks > it all horribly. > > Alan > [1] If you think about it a wait for no references is the same barrie= r as > a revoke but a blocking one. > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html