On Tue, Jan 28, 2003 at 04:15:41PM +0000, Matthew Byng-Maddick wrote: > On Tue, Jan 28, 2003 at 11:04:43AM -0500, Christopher Armstrong wrote: > > Hrm, maybe I just don't know what's going on, but I'm not sure why > > this is a problem. Couldn't "call out to native functions" or perhaps > > "call out to native functions in this library" or even "call out to > > *this* native function" be a capability? AFAIC (which means "for the > > applications I'm interested in"), any of the three are still Good > > Enough. > > Oh, yes, it is still a reasonable capability, but at the point that you > allow that capability, you can forget any of the rest of them. (this is > of course, ignoring any possible buffer overruns/format string/double-free > or other types of vulnerability where you can change the executed code). > > > I guess what I'm saying is, sure, you can't stop a native function > > (which was called from parrot code) from doing whatever it wants, but > > you can still prevent the parrot code from using that function in the > > first place (right?). > > Yes, but looking at the current Perl core, a large number of the > day-to-day useful modules are written native (read: in C), so you end > up losing there. That's not to say that future ones will have to be, > but... In reality, however, the problem as I see it is that this is a > capability which, once acquired overrides all others (wheras the others > can be mutually orthogonal).
I don't see why. Why, for example, would socket access (a C-implemented feature, certainly) allow access to everything else? Presumably, the built-in parrot[/perl/python/etc] functionality is `trusted' such that it only does what it *says* it does (after auditing and removing 100% of the bugs, of course ;), and you can give out caps to them on a per-func/obj/whatever basis. But maybe I'm totally misunderstanding what you're saying. Are you just assuming there are bugs in all native built-in functions that are exploitable to gain other capabilities? An example would help. Anyway, even if you're right about access to native functions, the way I'm thinking I'd use this would be to have a trusted program (i.e., my imaginary virtual world engine) running various untrusted scripts from around the world. With such a system, we'll just give the untrusted code access to application-level APIs (which themselves will be managed with capabilities, to facilitate differing trust levels) -- no need to give them access to such things as file I/O and whatnot. However, I guess socket access would be required, as I plan on having them executed in a separate process (with ulimits) and talk to the main system through an RPC (i.e., sockets) mechanism, with probably a chroot/jail thrown in for good measure, but this is an easy thing to audit and I can't see ever requiring more low-level access. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project --------+ http://twistedmatrix.com/users/radix.twistd/
