[1706] in linux-security and linux-alert archive
[linux-security] Re: message rejected: Re: Re: Towards a solution of tmp-file problems.
daemon@ATHENA.MIT.EDU (Nick Andrew)
Fri Mar 13 02:05:40 1998
From: Nick Andrew <nick@zeta.org.au>
To: wolff@BitWizard.nl
Date: Thu, 12 Mar 1998 23:09:58 +1100 (EST)
In-Reply-To: <199803120800.JAA00931@cave.BitWizard.nl> from "wolff@BitWizard.nl" at Mar 12, 98 09:00:05 am
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
G'day Roger,
Forwarding a message from wolff@BitWizard.nl:
> Passing by fd means coding changes.
>
> The C compiler classically compiles you C program to preprocessed C
> code in /tmp/ccxxxxx.i, throws that at the first compiler pass, ends
> up with /tmp/ccxxxxx.s, throws the assembler at that file, gets
> /tmp/ccxxxxxx.o and finally throws a linker at that file to get what
> you wanted. All these are passed by filename, and unlinked afterwards.
>
> I have lots of shell scripts that need to store temporary files
> (Editing one right now!) and pass the filename to the next program....
[mod: deleted a few lines intended for the moderator -- REW]
The file descriptor to which I am referring is _not_ the file descriptor
which is the contents of "/tmp/ccxxxxx.i". It is a file descriptor which
enables a holding process to open "/tmp/ccxxxxx.i" without any possibility
of another process (which does not hold the file descriptor) opening the
same file because ... the namespace which contains the file(s) is
inaccessible to processes which do not hold the file descriptor.
Its behaviour is more like a capability than a file. You might wonder why
it is a file descriptor rather than some other object, or setting, or
environment variable. Well, it doesn't actually matter to me - what's
important is that it is something which can be shared amongst a group
of processes without those processes necessarily having to do anything
to participate in that sharing. I just happen to think a file descriptor
is probably the right vehicle given that the major problem which we are
fighting here is a flaw in the Unix API, namely too much reliance on
non-atomic operations on pathnames, and not enough atomic operations.
Unix _will_ _be_ _fixed_ _eventually_ and although I don't know what the
fixed APIs will be, I think the right way to fix filesystem races is to
figure out how the system _should_ work, maybe implement that, and build
in backward compatibility for existing code such that it approximates
the right behaviour.
> Now how is this different from "working" in a different directory?
Because other (unrelated) processes can still see the directory. If you
can guarantee that a set of processes can see a directory which contains
named temp files, and no other processes can see it, then you have
behaviour which is equivalent to mine (suggestion, that is, I don't pretend
it's a solution until there's been some kind of formal logical proof).
> Setting a $TMPDIR is one way, making /tmp a varlink is another?
I'd have to defer to Theo De Raadt on the answer to that question. He has
more experience. I think setting TMPDIR would work fine, except that the
processes which are using that directory are still subject to the same
filesystem races which haunt us again and again. In other words, it doesn't
work. I think making /tmp a varlink is equivalent to setting $TMPDIR
except that the "expansion" of the varlink is now under kernel control,
or sysadmin control, rather than process control. Kernel isn't supposed
to set policy. Sysadmin can do that, but it isn't terribly flexible.
Processes themselves should be able to set the policy on expansion of the
varlink, and from what I recall of the previous messages in this thread,
that has been proposed, but I see two issues: a user process shouldn't
be able to set the policy on expansion of a varlink which a root process
is going to use, and secondly back to the basics, it doesn't stop filesystem
races.
> Your private namespace is specifically geared towards this one
> problem. Once you have varlinks you'll find that they are quite a
> useful feature, which not only works for /tmp ....
You seem to like these varlinks a lot. I don't have any problem with the
idea of varlinks. I don't see them as a security fix though. Varlinks
could be quite useful for unprivileged processes.
Aleph One has replied to one of my messages with some interesting points.
I'm going to reply to that.
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
