linux security - Mar 1998 - Re: message rejected: Re: Re: Towards a solution of tmp-file problems.

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/

On Thu, 12 Mar 1998, Nick Andrew wrote:
> 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.
Currently, most "privilege boundaries" in unix are determined by uids
and
gids. I think it is the complete waste of effort to invent something
with finer granularity for one specific purpose (/tmp).
> Its behaviour is more like a capability than a file. You might wonder why
Yes, capabilities are nice, and solve many security probs in an elegant
way... Anyone willing to make a hybrid of Linux and KeyKOS? :)


--Pavel Kankovsky aka Peak   [ Boycott Microsoft -- http://www.vcnet.com/bms ]