Re: [9fans] getenv/putenv

Re: [9fans] getenv/putenv

[presotto]

[-- Attachment #1: Type: text/plain, Size: 1990 bytes --]

There is rfork(RFNOMNT) which forbids a process (or its later children)
from walking (therfore binding) anything in # except #{|decp} and from
mounting anything period.

If you take a subtree of the file system, bind onto it what you
want, bind the subtree onto '#/', and then rfork(RFNOMNT), you
effectively sandbox a process.  If we also disallowed unmounts,
we could remove the restriction of a subtree.  It would be
nice if someone was willing to experiment a bit on what
constituted a generally useful (and hopefully minimal) set
of controls.

We also have the special group 'noworld' on the file server.  Anyone
in that group has no world (perm & 7) permissions to access files
on the file server.  It's an attempt from the file server side of
protecting accidental disclosure to files that certain groups of
users shouldn't see.  For example, we have a bunch of astronomers
that use our systems from the outside.  They have signed no
agreements with Lucent and are prohibited from seeing stuff
belonging to anyone else here lest an accident occur.  Their
telnet, ftp, and ssh sessions are started in an RFNOMNT sandbox
that binds in only the main file server and the outside network.
They are also members of noworld so that they can't see files
other than from their own group (and themselves).  I consider it
a failed experiment mostly because it didn't last long enough.
It did prove that RFNOMNT by itself wasn't enough.  We couldn't
just give them access to /bin and a few other directories because
we just don't control well enough what goes into them.   Instead
we had to create a complete subworld that included the /bin, /lib,
etc. files that they needed.  The 'no world' was just a second
protection in case our name space failed (because of bad
implementations).  It was a reasonable precaution since it was
very possible to walk out of your circumscibed namespace before
rob's last rewrite (and probably still is via some bug or other).

[-- Attachment #2: Type: message/rfc822, Size: 2937 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] getenv/putenv
Date: Mon, 19 Mar 2001 17:21:20 +0200
Message-ID: <20010319172118.U10659@cackle.proxima.alt.za>

On Mon, Mar 19, 2001 at 09:40:37AM -0500, presotto@plan9.bell-labs.com wrote:
> 
> I think you're right.  We not as env crazy as Unix is so the risk is
> lower but not nonexistant of somehow fooling a program to write
> something, so why have it at all.  Anyone else want to comment?
> If not, I'll just check for '/' in getenv/putenv names and punt
> if I find one.

Maybe unrelated to the above, and maybe not altogether, although
I can't quite make the connection (been up too long :-)

Been thinking that there ought to be an API/9P function to "drop"
irrecoverably parts of the user namespace.  Make them go away in
a particular context.  You can always mount a lower branch and make
the rest go, if you want to.  Maybe even keep the mount point but
make its contents invisible, or whatever (this last could be done
as things stand now, in a practical sense, bit it is reversible,
which I think should not be the case).

Of course, such a feature may already exist and I'm just displaying
my ignorance, but I have thought about it and nothing I've looked
at seemed to do the trick.  If on the other hand you Bell Labs
folks have looked at it already and discarded it as possibility,
I would be curious to know why.  From my point of view it is an
interesting way to provide a degree of security and protection,
specially against trojan horses.

++L

Re: [9fans] getenv/putenv

[Lucio De Re]

On Mon, Mar 19, 2001 at 09:40:37AM -0500, presotto@plan9.bell-labs.com wrote:
> 
> I think you're right.  We not as env crazy as Unix is so the risk is
> lower but not nonexistant of somehow fooling a program to write
> something, so why have it at all.  Anyone else want to comment?
> If not, I'll just check for '/' in getenv/putenv names and punt
> if I find one.

Maybe unrelated to the above, and maybe not altogether, although
I can't quite make the connection (been up too long :-)

Been thinking that there ought to be an API/9P function to "drop"
irrecoverably parts of the user namespace.  Make them go away in
a particular context.  You can always mount a lower branch and make
the rest go, if you want to.  Maybe even keep the mount point but
make its contents invisible, or whatever (this last could be done
as things stand now, in a practical sense, bit it is reversible,
which I think should not be the case).

Of course, such a feature may already exist and I'm just displaying
my ignorance, but I have thought about it and nothing I've looked
at seemed to do the trick.  If on the other hand you Bell Labs
folks have looked at it already and discarded it as possibility,
I would be curious to know why.  From my point of view it is an
interesting way to provide a degree of security and protection,
specially against trojan horses.

++L

[9fans] getenv/putenv

[presotto]

	My inclination would be to have the libc getenv() and putenv() check
	their args. It costs almost nothing, and the less potentially dangerous
	things the client has to think about checking the better.

I think you're right.  We not as env crazy as Unix is so the risk is
lower but not nonexistant of somehow fooling a program to write
something, so why have it at all.  Anyone else want to comment?
If not, I'll just check for '/' in getenv/putenv names and punt
if I find one.