[9fans] Plan9 security, environment and namespace

[9fans] Plan9 security, environment and namespace

[G.David]

>From: "G. David Butler" <gdb@dbSystems.com>

>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

[9fans] Plan9 security, environment and namespace

[G.David]

>I don't know of any programs that expect another concurrent process
>to change the environment.  In Plan9 it can be used as an IPC, but
>is it?

I found one that depends on the fork(2) behavior, init(8).  It expects
to run rc(1) scripts and have its environment and name space changed.
Easy to fix, change fork() to rfork(RFPROC|RFFDG).

On a broader note, I think there needs to be a discussion of the
current environment and namespace conventions regarding [r]fork(2).

I have addressed some security issues in the past regarding the
user "none".  As explained earlier, I believe "none" should be
a 4th class citizen (1st is user, 2nd is group and 3rd is other)
that is excluded from other.

Another issue is the default path in rc of (. /bin) in /rc/lib/rcmain.
This should be at least (/bin .) or, as I run it, just /bin [requires
a small change int /sys/src/cmd/init.c of 'lib/profile' to
'$home/lib/profile'].

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?

In the case of rc we can add flags to change the behavior, like:

term% flag N -
term% bind -a $home/bin/$cputype /bin
term% bind -a $home/bin/rc /bin
term% flag N +
term%

Using N for RFNAMEG, E for RFENVG, R for RFREND and F for RFFDG.
The default for each would be set in /rc/lib/rcmain.

Any comments?

David Butler
gdb@dbSystems.com