From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <dd19e12ccb2d34fe06ce31e9540a86b2@proxima.alt.za>
To: 9fans@9fans.net
Date: Sun,  4 Jan 2009 07:19:35 +0200
From: lucio@proxima.alt.za
In-Reply-To: <20090103235716.GG8355@masters10.cs.jhu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] sendfd() on native Plan 9?
Topicbox-Message-UUID: 7737f6c8-ead4-11e9-9d60-3106f5b1d025

> '#p'
> allows any of my namespaces to debug processess in any other, '#s' is too
> global, and /net seems to allow any of my processes to manipulate any of my
> other processes' network connections (though I've not tested in detail to
> see what's possible.)

So you're saying that (a) a jailed process should not have access to
the #-devices at all and (b) their equivalent /proc, /srv and /net
ought to be configured as part of the jail and should not be
modifiable.

Plan 9 source often short-circuits the possibility that #-something is
not bound to the conventional place (#v comes to mind as a frequent
culprit) but that is a form of laziness that could be corrected by a
careful source audit.  In which case it would be possible to treat #X
as another of those security issues that needed special treatment for
Factotum and have a kernel request that puts the #-space out of
bounds.

Would that satisfy your requirements?  Oh, sure, I haven't ever used
#| directly and I'm a bit ignorant of consequences, but the rest seems
feasible.

Another aspect I noticed is that what you seem to need is a
finer-grained construction of #p and #s, but being able to construct
them one layer further down the hierarchy might suffice.

Just an uneducated opinion, I've had little occasion to study those
specific devices or the others in any detail.  But I am curious of
where this discussion could lead.

++L