[1714] in linux-security and linux-alert archive
[linux-security] Re: Re: Re: Re: Towards a solution of tmp-file problems
daemon@ATHENA.MIT.EDU (Nick Andrew)
Fri Mar 13 06:13:09 1998
From: Nick Andrew <nick@zeta.org.au>
To: linux-security@redhat.com
Date: Fri, 13 Mar 1998 10:35:43 +1100 (EST)
In-Reply-To: <Pine.SUN.3.94.980311115750.17800A-100000@dfw.dfw.net> from "Aleph One" at Mar 11, 98 12:10:08 pm
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
Forwarding a message from Aleph One:
> On Thu, 12 Mar 1998, Nick Andrew wrote:
>
> > 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 will break applications that need to stat files to check if other
> instances of itself are running (e.g. pine).
See the latter part of my first message in this thread; the part to which
you are responding requires that users of unlinked temp files pass a
file descriptor to the open temp file, which doesn't solve the problem for
shell scripts, which typically write to a temp file in a subprocess then
read from the same temp file in the next subprocess.
The latter part of my message suggests a sharing/partitioning scheme in
which processes participate in a sharing domain through holding a file
descriptor which provides access to a particular sharing domain. This
file descriptor typically remains open across fork/exec and so subprocesses
can participate in the same sharing domain without having to do anything
special (that's how scripts continue to work). Processes which do not
hold the file descriptor are partitioned; that is how we get extra security.
A process may participate in multiple sharing domains or in none. If a
process does not know about sharing domains, it inherits the sharing
domain(s) of its parent by inheriting the open file descriptor(s) which
were passed across the exec call.
For example: a user's login process could setup a sharing domain in the
filesystem as, say "/tmp". All processes descended from that login process
would see a common set of files in /tmp. Say the user runs a setuid
process. The setuid process can establish its own sharing domain under
"/tmp" and any subprocesses will see a common set of files in /tmp, which
will not include the user's files and the user will not see the setuid
processes' files. The setuid process can safely call programs like "sort"
and "gcc" knowing that the temp files which they use cannot be hijacked.
> This touches on the core problem of why even though the /tmp problem is as
> old as UNIX is has never been fixed. There has just never been a standard
> definition of what /tmp is used for. Every solution everyone has proposed
> break one of the uses of /tmp. It used for temporary disk space, temporary
> files, interprocess communication between process of the same uid,
> IPC between processes of different uids, etc. Why one do you want to give
> up?
Good point. Very good point in fact, which leads to a prerequisite activity:
define all the various incompatible uses of /tmp and separate them, so there's
a separate directory for (say) inter-user file sharing compared to private
temporary files.
> > 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.
>
> O_UNLINK would not help. So now instead of simply truncating, overwritting
> or appending to a file and attacker can now also deleted it by playing
> with symlinks. What you need is a O_NOSYMLINKS flag to open to tell it to
> refuse to honor symlinks.
O_UNLINK is an atomic operation which protects the file after it is open;
you are correct that further atomic operations are required to protect the
process by giving it certainty that it is opening the file it expects.
All this is helpful for processes which are security-conscious, it doesn't
help non-security-conscious processes at all.
> [REW: (Some of the...) Comments in the source, and, as far as I can
> see, the source itself, say that O_EXCL in 2.1.x means that no
> symlinks will be followed on the final stretch. This disagrees with
> the majority (but not all) of the unices out there, but is required to
> make things secure. "varlinks" are working over here ;-) ]
Has anybody done work on how to secure "find"? This is probably the
ultimate challenge in protecting against file hacking in /tmp ... to
guarantee that I as root can run "find /tmp -user bloggs -exec rm -f {} \;"
without deleting anything unexpected; once the correct way to secure
that case is known the rest of the solution will probably be clear.
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
