[1712] in linux-security and linux-alert archive
[linux-security] Re: Towards a solution of tmp-file problems.
daemon@ATHENA.MIT.EDU (Pavel Kankovsky)
Fri Mar 13 05:44:40 1998
Date: Thu, 12 Mar 1998 13:48:42 +0100 (MET)
From: Pavel Kankovsky <peak@kerberos.troja.mff.cuni.cz>
Reply-To: peak@kerberos.troja.mff.cuni.cz
To: linux-security@redhat.com
In-Reply-To: <199803090959.KAA01271@cave.BitWizard.nl>
Resent-From: linux-security@redhat.com
I can't resist the temptation to add my two cents... :)
On Wed, 11 Mar 1998, Aleph One wrote:
> 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?
You hit the nail, Aleph. The problem is /tmp is used/misused/abused in
many different ways:
1) temporary files generated by programs (ex: sort, man, perl -e)
2) temporary files created by users (ex: ls -lR / > /tmp/allfiles)
3) "well-known" place for caching, IPC, locks (ex: pine, X11)
(and God knows what else)
IMHO, world-writable /tmp ought to be abolished because:
Number 3 is a true abuse. When you avoid Scylla (symlinks and friends) you
get caught by Charibdis (denial of service) because the software relies
on an ability to work with files having a certain name. I have no easy
universal solution for this (I doubt such a solution exists at all).
Number 2 is misuse. It makes sense to allow the users create their
temporary files on a separate filesystem but they do not need a shared
directory. I think a private temporary area for each user is a perfect
solution.
For number 1, the private temp areas would probably work as well, plus it
provides a good deal of protection to all programs, even the stupid ones
(gcc, sort).
On the other hand, I do not think a magic "varlinked" /tmp is a good
idea because it would cause quite a lot of confusion among users ("Joe,
the file's in /tmp/xyz." Joe: "Where? I can't find it!") as well as
among set[ug]id programs.
On Thu, 12 Mar 1998, Nick Andrew wrote:
> Because programs that _were_ privileged but have set euid == ruid will put
> the tmpfile into a directory to which the user has access, I guess - and
> that's the root of the problem; the tmpfile _must_ be inaccessible to all
> but the processes which actually need it.
The program will create a _file_ to which the user has access (unless it
plays a tricky game with directories). A function creating a completely
anonymous file could help here, nevertheless, a privileged program
using the credentials of the user to create a _sensitive_ file is lame.
--Pavel Kankovsky aka Peak [ Boycott Microsoft -- http://www.vcnet.com/bms ]
P.S. Off-topic comment to the original post:
On Mon, 9 Mar 1998, Rogier Wolff wrote:
> not to give those rights away. A non-setuid program should not have to
> worry about buffer overruns (you can crash the program, wow!). It
Of course it SHOULD worry. Any network client is a good example.
--
----------------------------------------------------------------------
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
