linux security - Mar 1998 - Re: Re: Towards a solution of tmp-file problems

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/

Nick Andrew:
> 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).
Although I like that last suggestion (name space passed by fd), it
may violate the principle of least surprise, unless that private
name space can be made available to non-login processes such as
those run from cron or from .forward files.

Of course, the ability for a process to become any user without
any prior login authentication is one of the weakest and most
powerful features of UNIX at the same time.  

But the concept of an authenticated setuid() call is perhaps better
discussed in a separate thread.

	Wietse

On Thu, 12 Mar 1998, Nick Andrew wrote:
[snip] 
> 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.
Maybe I''m not quite awake enough yet (and if so just ignore me), but
this
looks very similar to what ''chroot'' does.  

  Taken from the chroot(2) manpage:

DESCRIPTION
       chroot  changes  the  root  directory to that specified in
       path.  This directory will be used for path name beginning
       with  /.   The root directory is inherited by all children
       of the current process.

       Only the super-user may change the root directory.


This provides a "jail" in which to run the process that theoretically
can''t be escaped.  It just needs to be used in such a way that no other
process can get in either.


-Andrew

In message <199803112136.IAA23600@gidora.zeta.org.au>, Nick Andrew
writes:
>Forwarding a message from Rogier Wolff:
<SNIP>
>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.
It''s the obvious way to do it to me. Just ''steal'' the
plan 9 code for mounting
directories on a per-process basis, with options to fork() which allow those
changes to the directory structure to be visible to child processes or not. Plus
a change can be made ''permanent'' such that child processes
can''t undo it.
ie. /$HOME/tmp replaces tmp which would be done by login or something
similar. Everything stays the same except security conscience programs and
''sharing'' programs that use tmp for IPC or whatever.

For security programs a wrapper around them replaces /tmp ($HOME/tmp)
with a ''secure'' directory it constructed for the
''secure'' program, for other
programs is ''merges'' the two directories, so that /tmp now
appears to
contain all the stuff in both $HOME/tmp and the ''secure''
directory.

For IPC purposes a wrapper would have to replace /tmp with /mnt/ipc or
similar...

Because tmp is used for may purposes a solution that requires no client
code changes may be impossible (how do you know if the file is meant
to be secure or meant to be shared?).

Sam

On Thu, 12 Mar 1998, Andrew R. Baker wrote:
> Maybe I''m not quite awake enough yet (and if so just ignore me),
but this
> looks very similar to what ''chroot'' does.  
> 
>   Taken from the chroot(2) manpage:
But chroot is a system call that requires root privileges to utilize.  It
would be useless to any of the other hundreds/thousands of programs that
use /tmp and aren''t setuid root.

- Oliver

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Secure Networks Incorporated.  Calgary, Alberta, Canada, (403) 262-9211