But of course I'm assuming object-oriented design. Because no matter
what way you look at it, every operating system is consisted of objects,
even though borders between them may be very blured due to a limited
access control mechanism used, such as ACLs or capability lists, that
prevents efficient fine grained access control for one reason or
another.
> 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
> 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)."
I really don't see why this should be a problem with capabilities.
> In your model, a "pure capability system" that only checks items at the
> 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
It has been done a number of times.
> 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.
You might as well have a capability to each of the individual ports
only. It could be given to you by inetd as a subset of its own
capability for example (if you're a server, started by inetd).
> 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
You can always emulate an interface. You just can't make it better than
it fundamentally is.
> 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.
I see.
Thank you for the debate then and good luck,
Andrej
-- Andrej Presern, andrejp@luz.fe.uni-lj.si
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu