lkml.org 
[lkml]   [1998]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 2.1.97] more capabilities support

>With pure capabilities on the other hand, time and storage required to
>perform a check is always constant: 0 (zero), because the check is done
>implicitly at the object border, so the object does not have to waste
>any resources to perform it explicitly.

Ah, now I see where the confusion is coming from. Andrej, you are using
"pure capability" in a way that's very different from most of the
published literature. You're assuming an object-oriented design, and
the Unix/POSIX interface is manifestly *not* object-oriented.
Furthermore, if you look at the literature, the capabilities predate
object oriented designs by a very long time.

Your idea of checking at the object border might work fine if you have
objects, and if the objects are properly designed ahead of time with
security properities in mind. For example, let's take it out of the
kernel application domain, and talk about a purchasing system, since
it's easier for most people to understand.

Suppose the interface involved is "purchase an item". If that is the
interface, than a check at the "object border" can only be, "allow the
user to purchase an item". However, this is not useful; we may want to
express the authorization "allow the user to purchase items under
$5,000". Or perhaps the authorization rule is "allow the Ted to
purchase normal items under $5,000 but not radioactive chemicals
(because he hasn't taken the radiation safety course yet)."

In your model, a "pure capability system" that only checks items at the
border can only do the first check --- "purchase an item". It's
possible you could change the interface to allow checks to only happen
at the object border, but I question whether it really can be done. In
any real system, the application usualy has to get involved in
authorization decisions, because such decisions tend to involve
application-specific decisions. In the kernel, for example, it's not
enough to block out all socket calls. You might want to block out the
ability to bind to ports below 1024.

One could imagine a totally different kernel API which was completely
and totally incompatible with POSIX, where you might be able to make all
interface checks "at the object boundary". However, for the reasons
stated above ---- I doubt you could make it work even then.
Given that we want to be POSIX compatible, the POSIX capabilities really
are the best way to go. If you want to play with a totally
object-oriented kernel interface ---- go try to find a research OS
that's playing games in that area.
- Ted


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [from the cache]
©2003-2011 Jasper Spaans