[3303] in bugtraq
Re: Tired of /tmp? Here's a proposed solution
daemon@ATHENA.MIT.EDU (mdr@vodka.sse.att.com)
Wed Aug 28 18:11:46 1996
Date: Wed, 28 Aug 1996 17:17:57 -0400
Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: mdr@vodka.sse.att.com
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
In-Reply-To: <Pine.LNX.3.95.960828152849.399A-100000@litterbox.org> from "Sean
B. Hamor" at Aug 28, 96 03:36:37 pm
On our B1 secure host, process's access into / tmp are diverted into
/tmp/<label> directories with the partitioning being on the security
label associated with the process.
That means that an trusted user process gets a different view of /tmp
than a trusted system process such as 'ps'.
So imagine that a user desires to exploit a race condition of some
sort in a ps. Suppose ps were to create a file in /tmp and then
try to chmod it to prevent the user from modifying its contents (of
course this would never happen in real life right :) On our host,
ps would create a tmp file in the real /tmp/system-level, however the user
would be looking for it in /tmp/user-level. Neither process would be
aware that its view of /tmp was really a subdirectory. Neither
process would be able to see the other's files. Sufficiently
privileged processes can see all of /tmp (for example to routinely
remove old files).
The above description illustrates that the kernel could provide
virtual /tmp' that are separate per user without requiring any
user-level code. This is not without problems, because some
software is written to _rely_ on /tmp as a globally accessible
directory, and uses it for interprocess communication by creating
lock files and such trash.
Our B1 system goes beyond this a applies the same kind of separation
to /dev and IPC keys for semaphores, sharedmemory, etc.
Mark Riggins
Secure Systems Engineering
AT&T Labs
~
>
> # >Well, this is a good quick hack. What about removing the CONCEPT of
> # >public writable filesystems like /tmp.
> #
> # Agree 100%.
> #
> # The best solution would be, IMHO, to give each user his or her
> # personal temporary directory, under /tmp/username, mode 700.
> # /tmp can stay 1777 for stuff like make files accessible to other
> # users.
>
> How about using a method similar to the way SCREEN handles TEMP files?
> Obviously allow users to save files in /tmp/ that would blow their quota,
> but as far as software created TEMP files, create or use a 700 directory in
> /tmp/ similar to this:
>
> hamors (4 13:29) system:/tmp/screens> ls -al
> total 6
> drwxr-xr-x 3 root bin 512 Aug 28 05:42 .
> drwxrwxrwt 3 bin bin 512 Aug 28 13:28 ..
> drwx------ 2 someone 1000 512 Aug 28 05:42 S-someone
>
> I'm not sure how this would be globally implemented, though...
>
> Finger hamors@ishiboo.com /\_/\ mailto:hamors@litterbox.org
> for PGP public key block. ( o.o ) http://www.ishiboo.com/~hamors/
> alt.litterbox, The Home of TOCA > ^ < http://www.litterbox.org/~hamors/
> Hi! I'm a .signature virus! Add me to your .signature and join in the fun!
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQEVAwUBMiSfzDU6HlxZIJ+FAQHvGQf/aBlEsbqSiCeZaZcCHXn77OuAdFLGy7hh
> 5DW8z99Ahr0V1XnKOX5uBBlgCCXkyuqIymIgKjRMSIQNIkmZJ3kcc1RQJhc22C5h
> nQjPVnDPwHSpChSVnMTgTgRqWaQCBpXdyuIrhR1uNcMuUg0GZuzOXGMsQqOa21gG
> wsr/Ocblgt9Al2g3x05Chk/bz2/PMHyKvZvyWVlMAjDaJhrnV/T91KNB1u4aKpkd
> tG+SgLiCH+qu9fCkmy9jWY0p6gKkw7PZZPbAWVYC2spckTlibuX+N2UBBGfK8Q22
> iwSkVUkjH1EdWrGHKbKEfm86g45L0fxnNjhjgsIsT3d9dtNNVVX9Lw==
> =yLWV
> -----END PGP SIGNATURE-----
>
>
