linux-kernel - Re: O_NOLINK for open()

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: <46E85528.3010405@zytor.com>
Date:	Wed, 12 Sep 2007 14:07:52 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Brent Casavant <bcasavan@....com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: O_NOLINK for open()

Brent Casavant wrote:
> 
> I could mmap a temporary tmpfs file (tmpfs so that if there is a
> machine crash no sensitive data persists) which is created with
> permissions of 0, immediately unlink it, and pass the file
> descriptor through an AF_UNIX socket.  This does open up a very
> small window of vulnerability if another process is able to chmod
> the file and open it before the unlink.
> 

To avoid this window, typically one creates a temporary directory first,
with 0700 permissions.  Make sure you verify that you actually created
the directory, and watch out for symlink attacks.  Then you create the
file in that directory.

This doesn't prevent another process owned by the same user (or root)
from attaching, but such a process can ptrace you or touch yoour /proc
spaec just as well, so you're screwed anyway (modulo SELinux-type policies.)

> However, it occurs to me that this problem goes away if there were
> a method create a file in an unlinked state to begin with.  However
> there does not appear to be any such mechanism in Linux's open()
> interface.  A bit of Googling indicates that Hurd has an O_NOLINK
> flag which seems to accomplish what I'd need, but Linux doesn't
> implement such a flag.  There was some discussion of this in various
> lkml threads in the past, but none that went anywhere.  Perhaps
> the best an explaining why other mechanisms (i.e. directories
> with particular permissions aren't a solution) is:
> 
> 	http://marc.info/?l=linux-kernel&m=93032806224160&w=2
> 

This link talks about file flags handling.  I don't see the relevance to
this problem at all.  However, this is a very long thread, so if there
is anything specific that you want to point to, then please elucidate.

> Of course it is reasonable to take the stance that if root or the
> daemon's user are malicious, all bets are off anyway.

Yup, see above.

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