Re^2: Auditing BEGIN blocks?

[An Ode to the Granovetter Diagram is a nice intro to the concepts I'm dealing with]

Unfortunately no, that wouldn't work. I haven't fully explained why I'd like to audit perl code so your suggestion is reasonable given the supplied information. I've been spending time learning about Capability system and this is something that would be really useful for that sort of thing.

While I'm not aware of all the term's connotations and requirements the general idea is to end with something with properties like a Trusted Computing Base. This might mean that a set of objects exist in a context where arbitrary perl code is restricted. The specific example I mentioned in the original question isn't even properly testable using current perl technology. For example - I'd have to disallow use of unpack/pack with use of my() and global variables as patterns since those can introduce pP. That's a finer distinction than simply disallowing all use of pack/unpack. Even better would be to allow full use of pack/unpack but just turn off it's memory reading abilities. And this is just one example - there are plenty of other interesting constructs that would need to be pruned away.

It might be possible to use Safe if the object set's source code was continually compiled on each object invocation but you can see how that's really suboptimal. The only reasonable solution for current perl5 technology would be to split the program into separate process spaces (fork/threads/whatever) and do IPC to get object computation. Perhaps POE or something that can manage the details of IPC. But only provides one perl section protection from another - there's no internal protection without using Safe's cudgel, PPI's wobbly blade or my approach's unlocked gate. If there was a reliable way to audit a complete opcode tree then I'd be getting somewhere. Going farther it'd be good to insert assertions into the tree so then things that can only be known at runtime can be tested then.

Anyhow, thanks for the advice. I'll just hope perl6 is powerful enough to make some real magic happen. ;-)

Fun Fun Fun in the Fluffy Chair

Comment on Re^2: Auditing BEGIN blocks?

Replies are listed 'Best First'.
Re: Re^2: Auditing BEGIN blocks? by John M. Dlugosz (Monsignor) on Dec 19, 2002 at 19:16 UTC
It seems to me that using a raw pointer in pack/unpack is something that taint-checking should catch. That oversight should be trivially corrected by someone with patching experience. Well, making it check the pattern argument for taint-ness up front would be trivial, but would prevent pack/unpack from working at all with user-supplied patterns (probably a good idea). Having it note the tainted string and respecting only a subset of the commands would be more difficult. Ideally, the behavior would be controlled in a manner similar to the "re" pragma for a similar issue regex's. I think the taint concept in Perl fits nicely with the concepts you are studying. Perhaps you can contribute some meditations for Perl 6 design and Perl 5 fixes (like this) as a product of your studies. That is, tainting seems the existing tool for this concept, how can it be improved or augmented to handle modern understanding of these concepts? —John	[reply]
Re^4: Auditing BEGIN blocks? by diotalevi (Canon) on Dec 20, 2002 at 17:16 UTC
Taint is nice and needs to be expanded and should probably also be applied to pack/unpack data and formats but this doesn't really address the problem I'm thinking about. In general, the idea is to use objects that are only capable of gaining access to and/or altering things to which access has been specifically granted. So no modification of globals, perhaps no access to globals (though that is a really extreme vantage point), no access via the symbol table to other things, no encapsulation violations from printf/sprintf/pack/unpack with 'P', no globs. I think a simulation of this might look something like this (in pseudo code because I'm lazy). The really unfortunate thing is that current perl5 requires you to constantly keep recompiling everything you intend to keep compartmentalized. It's so painful I've just rejected it out of hand. `# Object manager code - privileged context sub message { $object code = "perl code that defines the object behaviour"; %object data = (all the object's member data) $compartment = Safe->new # pass in the object's data $compartment -> share(%object data) # pass in the method to execute $compartment -> share( $message ) # Compile the object, execute the method and return # the $compartment -> reval( $perl code ) return $compartment -> return value }` [download] In this case I'm trying to adapt an E vat to perl. The closest analogues is perl that just plays by the rules (so voluntarilly no violations of encapsulation), Safe like I just half-outlined and perl in different processes. The multiple-process model is probably the only really suitable way of making this happen but then because there are no internal guarantees on privacy it's a poor vat. If the vat could audit all the code being given to it and disallow various things then that goes a long way toward having strong vats and might eventually get perl to compete with E. And why am I doing all this? Because I don't want to use E - a language I'd never heard of prior to this but want all the benefits. I gather that E uses the Java virtual machine as a base to operate in and that each vat (or compartment) is probably bounded at a single machine or process. E solves other problems related to mutually suspicious programs on distributed computers but along the way has a really nice security model. I'm stealing the security model. Fun Fun Fun in the Fluffy Chair	[reply] [d/l]