From: Brent Casavant <bcasavan@sgi.com>
To: Andreas Schwab <schwab@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: O_NOLINK for open()
Date: Wed, 12 Sep 2007 17:44:30 -0500 (CDT) [thread overview]
Message-ID: <20070912172519.N5573@pkunk.americas.sgi.com> (raw)
In-Reply-To: <jetzpza7ci.fsf@sykes.suse.de>
On Wed, 12 Sep 2007, Andreas Schwab wrote:
> Brent Casavant <bcasavan@sgi.com> writes:
>
> > 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.
>
> Only the owner can chmod a file, so why is that a vulnerability?
In this particular case because the user may not normally have direct
access to some of the data to be contained in that file.
Decryption keys in a key management system, in particular. If the
keys are passed over secure network links such that they only ever
exist in system RAM, and are not reachable via the filesystem, these
keys can be protected from disclosure to the user (short of /proc/#/mem
type of tricks). However, if there is even a brief window when the
user can gain access to the file, these keys are at risk of disclosure.
The problem can be addressed, in this case, by having the daemon half
of the design create these files, however it would provide a bit more
flexibility if the client side was also capable of creating them. It's
not a make-or-break problem, by any means, but does somewhat motivate
an O_NOLINK flag for open().
Brent
P.S. By the way, there doesn't seem to be a way to remove /proc/#/mem
files. That might be an additional nicety -- programs worried about
being snooped could unlink their own entry. /dev/mem and /dev/kmem
can simply be removed by the sysadmin of such a system. If all of
that were done you'd have to resort to attacking crash dumps, core
dumps, or via something like kdb to extract "hidden" data.
--
Brent Casavant All music is folk music. I ain't
bcasavan@sgi.com never heard a horse sing a song.
Silicon Graphics, Inc. -- Louis Armstrong
next prev parent reply other threads:[~2007-09-12 22:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-12 20:37 Brent Casavant
2007-09-12 21:07 ` H. Peter Anvin
2007-09-12 21:39 ` Brent Casavant
2007-09-12 21:46 ` H. Peter Anvin
2007-09-12 21:42 ` Andreas Schwab
2007-09-12 22:44 ` Brent Casavant [this message]
2007-09-12 22:49 ` Al Viro
2007-09-12 23:27 ` Brent Casavant
2007-09-12 23:48 ` Brent Casavant
2007-09-14 16:37 ` Goswin von Brederlow
2007-09-13 10:08 ` Gabor Gombas
2007-09-13 16:05 ` Brent Casavant
[not found] <92Haf-7z7-5@gated-at.bofh.it>
2007-09-12 22:33 ` Bodo Eggert
2007-09-13 9:13 ` Jan Kara
2007-09-14 9:07 ` Bodo Eggert
[not found] ` <92TO5-246-1@gated-at.bofh.it>
[not found] ` <92Zqu-2ur-1@gated-at.bofh.it>
2007-09-14 10:30 ` Bodo Eggert
2007-09-14 10:50 ` Andreas Schwab
2007-09-14 17:26 ` Bodo Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070912172519.N5573@pkunk.americas.sgi.com \
--to=bcasavan@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=schwab@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®