Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757821AbZLGOpE (ORCPT ); Mon, 7 Dec 2009 09:45:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757341AbZLGOpC (ORCPT ); Mon, 7 Dec 2009 09:45:02 -0500 Received: from earthlight.etchedpixels.co.uk ([81.2.110.250]:55778 "EHLO www.etchedpixels.co.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756689AbZLGOpA (ORCPT ); Mon, 7 Dec 2009 09:45:00 -0500 Date: Mon, 7 Dec 2009 14:46:23 +0000 From: Alan Cox To: Miklos Szeredi Cc: miklos@szeredi.hu, luto@mit.edu, akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] vfs: new O_NODE open flag Message-ID: <20091207144623.692fbc1e@lxorguk.ukuu.org.uk> In-Reply-To: References: <20091202191549.1dbffa2e@lxorguk.ukuu.org.uk> <20091202204828.4fa0c108@lxorguk.ukuu.org.uk> <4B1A7159.3070101@mit.edu> <20091205202838.3456b6fc@lxorguk.ukuu.org.uk> <20091205231304.03a4af61@lxorguk.ukuu.org.uk> <20091207122346.6d18a8e1@lxorguk.ukuu.org.uk> <20091207130339.620b904b@lxorguk.ukuu.org.uk> <20091207131546.2af06647@lxorguk.ukuu.org.uk> <20091207141321.0964461d@lxorguk.ukuu.org.uk> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.6; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1708 Lines: 37 > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/