[1277] in linux-security and linux-alert archive
Re: [linux-security] Re: t bit and symlinks patch
daemon@ATHENA.MIT.EDU (David Holland)
Tue Oct 29 04:20:26 1996
From: David Holland <dholland@eecs.harvard.edu>
To: R.E.Wolff@BitWizard.nl (Rogier Wolff)
Date: Mon, 28 Oct 1996 16:33:12 -0500 (EST)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199610260941.LAA00829@cave.et.tudelft.nl> from "Rogier Wolff" at Oct 26, 96 11:41:49 am
> When I write a simple application, I don't have to think about
> preventing the user of my program to write to files he doesn't have
> access to. The OS does that for me. That's what it's for. If I write
> an applciation that is going to need an setuid bit, I KNOW I am getting
> into a big mess of security issues. Then it is my responsibility to do
> it good.
>
> So to keep with the Unix philosophy "what should be simple actually is",
> the system should provide sufficient security for the standard use of
> /tmp.
You are right.
> If the suggested fix by Andrew can be made watertight, it could be
> sufficient.
As per a previous message, I don't think it can be.
> Another way would be to make context sensitive symlinks. (Anybody
> remember Domain-OS?). This would allow you to make /tmp a symlink to
> $HOME/tmp . There are many more interesting uses of this feature...
> Any volunteers? :-)
This sounds a lot more interesting.
What context do they reference, though? Reading environment variables
out of user space sounds horrendous.
[REW: Let me answer that question here: I was thinking about allowing
user processes to submit a variable to the kernel for inclusion into
its "symlink-environment". If you'd allow a process to set it's parent
environment, you'd only need one special program to set them, which
you can call from /etc/csh.cshrc or whatever YOU use. Otherwise you'd
have to make a special shell-builtin for every shell on earth...]
--
- David A. Holland | VINO project home page:
dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino
