9fans archive / 1998 / 02 / 56 /    prev

From: G. David Butler gdb@dbS...
Subject: [9fans] Plan9 security, environment and namespace
Date: Fri, 27 Feb 1998 08:35:00 -0600

>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@dbS...