mailing list archives
Re: personalized /tmp (was: BUGTRAQ ALERT: Solarix 2.x
From: scott () Disclosure COM (Scott Barman)
Date: Wed, 16 Aug 1995 16:44:28 -0400
On Wed, 16 Aug 1995, =?ISO-8859-1?Q?Thomas_K=F6nig?= wrote:
Ya know, if /tmp isn't world writeable doesn't that defeat the purpose of
having a /tmp at all?
It should be possible to have a temporary directory for each user,
such as /tmp/username (or any other place you care to put it).
This would fix a great many problems, and apart from UNIX tradition,
I see no reason against it.
I guess it's because I teach systems administration that I do not have
this problem. I always tell my students to make sure the sticky bit is
on /tmp (and /usr/tmp where it exists). Funny thing... I practice what
I preach!! I just didn't know it was such an issue. I figured it was
one of those things that Sun did because they sell an OS without all the
security features applied, rather than making the sysadmin take them
However, after reading the above, I got an idea...
For a paper I was writing, I was re-reading Cheswick's description on
his following Berferd, a hacker entering AT&T's system. His solution
was to create a "jail," essentially a chroot area that looked like a
real system, and let Berferd play there. This gave me an idea...
What about having a form of chroot so that a user, or a group of users,
can have their own environments. The only difference is that this
chroot can be set up to mount system directories read-only (/bin,
/usr/bin, &c). The limit of their mount is limited to directories
allowed (for example, you want to allow users access to all of /usr
with maybe the exception of /usr/etc--this scheme would deny the user
access to that directory). This way, each user can get their own /tmp
directory and this problem would not exist.
An administrator would set up their environment before a user logs in.
The user would have what looks like their own system. Additionally,
there would be no restrictions to setting up groups of users like
this, with different home directories as they do now.
(why do I get this feeling this sounds a bit like VM/370?)
Programs that needed "global" access (i.e., ps) can be written to do
their own chroot back to the real root to run. Programs like that
would have to be given permission to do that and design it into the code
(i.e., no setuid-like behavior). But this gets into things like
access lists, &c. that a lot of Unix folks don't like to hear about! :-)
scott barman DISCLAIMER: I speak to anyone who will listen,
scott () disclosure com and I speak only for myself.
barman () ix netcom com
"Micro$oft and Windoze/NT will be the cause of the de-evolution of
network security just as the original PC and BASIC was the cause of
the de-evolution of programming."