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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4B1A7159.3070101@mit.edu>
Date:	Sat, 05 Dec 2009 09:42:33 -0500
From:	Andy Lutomirski <luto@....edu>
To:	Miklos Szeredi <miklos@...redi.hu>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, akpm@...ux-foundation.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] vfs: new O_NODE open flag

Miklos Szeredi wrote:
> On Wed, 2 Dec 2009, Alan Cox wrote:
>>> You're still missing the point.  O_NODE is like a hard link, except
>>> the reference doesn't come from the filesystem but from a file
>>> descriptor.  From udev's perspective there's no difference.
>> I don't think I am missing the point here. You have a reference to an
>> object in the fs but you don't have a reference to the driver underneath
>> s the driver can change on you *while* you have the O_NODE open and fd
>> live. That cannot happen with a hard link and open.
>>
>> It isn't the same thing as far as I can see. You don't have the barrier
>> between the operations that occurs in the real open/close case because
>> they lock the driver.
> 
> The file descriptor opened with O_NODE allows exaclactly the same
> operations that a hard link to the device would, nothing more.  It's
> just a link to the *node*, except it doesn't increment the link count,
> the driver is irrelevant.
> 

I don't know what that means.  Do you mean that if:

root creates /dev/foo with 0666 perms
eviluser opens /dev/foo with O_NODE
root chmods /dev/foo to 0000
root unlinks /dev/foo

then eviluser can't open /proc/self/fd/whatever for O_RDRW

Because if eviluser could still open /proc/self/fd/whatever for O_RDRW 
(or anything else for that matter if O_NODE isn't set) then you have a 
security problem.

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