Capabilities workshop, followup questions

[Robert Watson]

On Sun, 18 Jun 2000, Andrew Morgan wrote:

> I think my impressions differed from yours(!):
> 
>  http://www.geocrawler.com/lists/3/SourceForge/4109/0/3905261/
> 
> Specifically, I felt:
> 
> * that there was little love expressed for global constraints
> (secure-level, global bounding sets etc.).

The jail concept is an interesting one, but I remember bashing
syscall-based bounding on at least one occasion :-).  What I should really
do is walk down the FreeBSD jail implementation, and see whether there are
calls that jail bounds but a POSIX.1e capability bound wouldn't prevent. 
If they exactly overlap, then inheritable capability bounds make a lot of
sense, if not, I'll have to think through it some more before deciding I'm
comfortable with it.  Having looked at the TRIX capability list, there are
some there that I prefer to the pure POSIX.1e ones.

> * DS17 were the exec rules we emerged with. I didn't hear anyone pushing
> the D16 model.
> 
> > Finally, I had a few questions about things we did not resolve.  First, in
> > the setuid world, modifications to the setuid binary result in removal of
> > the setuid bit.  Should modifications to a capabilities binary result in
> > capabilities being removed?  Richard Offer and I discussed issues of
> 
> IMHO Yes.

Another thing that we were talking about was the ability to modify system
libraries to circumvent inter-process manipulation limits.  I.e.,
typically processes with some sort of privilege are protected against
debugger access, etc.  As many shared library implementations make use of
mmap, it has proven possible in the past to cause inhapiness in
applications through direct modification of libraries on disk.  With MAC
integrity mechanisms in place, this isn't a problem as hopefully all
shared libraries are protected at a high integrity level, but without MAC,
the ability to directly modify libraries in use could result in the
ability to control a capability-endowed program to your benefit.  This is
not true for all implementations, needless to say, but it does reflect the
fact that moving from the UNIX uid mechanism to a capabilities mechanism
still leaves "root" with substantial powers by virtue of file ownership.

> > As I don't have a copy of D16, I can't comment on the rule set
> > differences, but it sounded to me like we firmly concluded the D16
> > inheritence rules were the way to go.  Could someone post the conclusions
> > on that?
> 
> ? I didn't leave with this impression at all.

Being unfamiliar with D16 (I have only D17), I assumed that the rules we
ended up with were from there, but I think I meant D15.  In any case, the
rules you describe in your post are the ones I had in mind.  :-)  I'd
really like to get a copy of some of the drafts other than D17 as that
would give me a bit more context on some of what was being said.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message