[1703] in linux-security and linux-alert archive
[linux-security] Re: Re: Towards a solution of tmp-file problems
daemon@ATHENA.MIT.EDU (Nick Andrew)
Thu Mar 12 05:50:47 1998
From: Nick Andrew <nick@zeta.org.au>
To: linux-security@redhat.com
Date: Thu, 12 Mar 1998 08:36:40 +1100 (EST)
Cc: nick@zeta.org.au
In-Reply-To: <199803111724.SAA00801@cave.BitWizard.nl> from "Rogier Wolff" at Mar 11, 98 06:24:11 pm
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
Forwarding a message from Rogier Wolff:
>
> Nick Andrew wrote:
> > Theo De Raadt pointed out (possibly not in this thread) that basing
> > protection on euid is not workable. Although I like the concept of
> > variable expansion in pathnames, I don't see it as a security mechanism.
>
> Why not?
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.
> Right! very important point: "not particularly security-conscious"!
> There are very many of those programs and I want them to be able to
> be safe, even if they are "not particularly security-conscious"!
Which includes shell scripts.
> And "not particularly security-conscious" means that they won't
> undergo code changes. They won't adhere to coding standards/coding
> changes that you propose.
Please reread my message more carefully. I suggested several ways to
achieve private namespaces for temporary files, and only one of these
(the O_UNLINK suggestion) required coding changes in the program which
actually creates/uses the temp file.
The other suggestions operate at a system level (new fs type), a
directory level (new mode on directories) or whatever level you like
(private namespace access passed by fd).
I think the final suggestion in particular is the only one which will
protect non-security-conscious scripts yet still allow child processes
of these scripts to share temp files without any possibility of unrelated
processes affecting same files. And the reason for that is that the
private namespace access can be imposed from above.
For example (and this is only an example), a private namespace may be
assigned for each user at login time (at the level of the login shell).
Thus, the user's "ls" commands see files in whatever directory the
private namespace is rooted, and for all intents and purposes it appears
to be an ordinary filesystem. Yet no other users can see this. User runs
unprivileged shell scripts, and shell scripts use this namespace. User
runs setuid shell scripts (shudders) and top-level setuid script defines
a private namespace which works for that process and all its children.
User's unrelated processes can't see the second private namespace but
not-particularly-security-conscious child processes of the setuid one
(e.g. sort) can, and their temp files are not visible to the user or to
any other user.
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
