Re: Re^2: Auditing BEGIN blocks?

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

Comment on Re: Re^2: Auditing BEGIN blocks?

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]