[1700] in linux-security and linux-alert archive
[linux-security] Re: Re: Towards a solution of tmp-file problems
daemon@ATHENA.MIT.EDU (Nick Andrew)
Wed Mar 11 12:42:06 1998
From: Nick Andrew <nick@zeta.org.au>
To: linux-security@redhat.com
Date: Thu, 12 Mar 1998 00:38:42 +1100 (EST)
In-Reply-To: <199803110817.JAA00942@cave.BitWizard.nl> from "Rogier Wolff" at Mar 11, 98 09:17:49 am
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
Forwarding a message from Rogier Wolff:
> Mark Whitis (whitis@dbd.com) wrote:
>
> > > A /tmp that is a symlink to /.tmp/$euid would do the trick.
>
> > However, there are some things which are broken by this. One case
> > which was pointed out to me was the unix domain sockets used by X11.
Theo De Raadt pointed out (possibly not in this thread) that basing
protection on euid is not workable. Although I like the concept of
variable expansion in pathnames, I don't see it as a security mechanism.
Please correct me if I misunderstand the basic problem: a process, not
particularly security-conscious, needs to be able to open and use one
or more temporary files, without the possibility of another process
interfering with those files.
Suggestions so far include per-user TMPDIRs, fixing all the code to do
safe open, and expanding the namespace to make the filename unguessable,
Per-user TMPDIRs don't improve security if a setuid program uses a user's
TMPDIR, which it will if the setuid program has given away privs.
Expanding the namespace avoids the symlink problem (e.g. symlink /tmp/aa12345
to /etc/passwd) but leaves temp files open to umask-related problems where
a hostile process overwrites a created file.
How about this idea, which I don't recall anybody mentioning yet: truly
anonymous temp files. Define a filesystem, directory or path such that
open() of any pathname under that root returns a file descriptor to a
new inode which is _not linked_ in that filesystem. The file thus opened
becomes a truly anonymous file - guaranteed to be newly created and
no other process can obtain the same file (except when the file descriptor
is explicitly passed by the opening process, through dup(), fork/exec and
the like).
This is not a solution intended to allow users to share files - sharing and
protecting are mutually exclusive requirements; let them share files
somewhere else.
There are several ways this could be implemented. One, as a new filesystem
type known to the kernel. I think it could be implemented fairly readily
with userfs backing onto an existing filesystem. Two, as a new semantic for
directories, complementary to the 1000 mode. Three, as an additional flag
to open() called, say, O_UNLINK.
I think the cleanest solution must be O_UNLINK - Unix really needs an API
overhaul, and atomic file operations is one of the areas which need a
facelift. Dennis Ritchie has been deservedly commended for designing
an OS interface which lasted over 20 years, but it's time to go back and
redesign it based on that experience.
[REW: Compatibility is VERY important nowadays. re: MSDOS.]
I believe this method will require code changes, not sure how much. I see
two categories: firstly progs which open a temp file, use it while open
and close/unlink it when done. I think these progs should use atomically
unlinked files by default. Second category includes progs which open a
temp file and perhaps expect to close and reopen the same file later,
or pass the pathname to some other program. Such progs would require
modification to utilise an atomically unlinked file, unless ...
... unless there's some way to create a kind of "private namespace"
for a process or family of processes. For example the shell running a
script could have a private /tmp namespace which would be visible to
the shell and all subprocesses, but nobody else. Any process could
create a new private namespace and arrange for it to be inherited,
and perhaps a mechanism for passing this private namespace to
unrelated processes may be useful.
[REW: Is this different from using $TMPDIR set to $HOME/tmp?]
It could be implemented by a new system call similar to chroot() except
unprivileged - but that introduces a new type of object into the
system, and other calls would be required to manage instances of this
object. It could also be done via (another) modification to open(), and
"access" to this private namespace would be equivalent to holding an
open file descriptor. Access could then be inherited using normal
mechanisms and transferred using normal mechanisms.
Nick.
--
Zeta Internet SP4 Fax: +61-2-9233-6545 Voice: 9231-9400
G.P.O. Box 3400, Sydney NSW 1043 http://www.zeta.org.au/
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
