Scientific Operations Bellum Gratia Artis

testing - 1998 - March - this message

[ next ]

Subject: Re: [9fans] Plan9 security, environment and namespace

From: "G. David Butler" <gdb@[REDACTED]>
Date: Thu, 5 Mar 1998 09:08:38 -0600

>From: "G. David Butler" 

>On a broader note, I think there needs to be a discussion of the
>current environment and namespace conventions regarding [r]fork(2).
>
>Now the issue of executing a program that changes the environment
>or namespace in unexpected or insecure ways is next.
>
>"Normal" programs should be executed so the parent is protected from
>errant behavior. In other words fork(2) should perhaps be
>rfork(RFPROC|RFNAMEG|RFREND|RFENVG|RFFDG).
>
>The problem then becomes how does a process know when it is ok or
>necessary to let the wall down?

I've been working with this for a while and here are my further
thoughts.

Since the terminal is executing in the context of only one user,
that user should have free reign to change whatever environment
or namespace whenever desired. Even though it is possible for another
user to plant a trojan horse where an unsuspecting bind can use
it at the central fileserver, that would still occur since the bind
is ineffective with the "wall" up.

The aux/listen already separates users on the cpuserver with RFENVG
and RFNAMEG.

At any time the user can errect a "wall" by simply starting a rc
script with "rfork en" or creating $home/bin/rc/command to front
a real command in /bin with:

#!/bin/rc
rfork en
exec /bin/`{basename $0} $*

Given these options, I don't think it is worth the extra overhead
to force RFENVG|RFNAMEG on every fork(). As far as the surprises
that are in store for the unsuspecting Plan9 user, caveat emptor.

David Butler
gdb@dbSystems.com