[1702] in linux-security and linux-alert archive
[linux-security] Re: Re: Re: Towards a solution of tmp-file problems
daemon@ATHENA.MIT.EDU (Aleph One)
Thu Mar 12 04:36:01 1998
Date: Wed, 11 Mar 1998 12:10:08 -0600 (CST)
From: Aleph One <aleph1@dfw.net>
To: linux-security@redhat.com
In-Reply-To: <199803111338.AAA11388@gidora.zeta.org.au>
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
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).
> 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.
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?
> 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.
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. But if you add such a flag your must recompile
all program you want to protect. If you are going to recompile all those
program you might as well fix them to use open correctly in the first
place. O_UNLINK is also useless in a directory with the sticky bit on
(unless you are root) since you cant delete others (the attacker) files.
[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 ;-) ]
> 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
>
Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
--
----------------------------------------------------------------------
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
