Re: [Perlplusplugin-developers] authorization?

[Dmitry K. <dk...@pl...>]

	Hi Frank!

On 14 Sep 00 at 09:54, "Frank" (Frank Holtry) wrote:

 Frank> But as I understand it (and I'm no expert on Perl internals),
 Frank> Opcode doesn't control the parsing of eval'd code unless that code
 Frank> itself includes a 'use Opcode'.  So a malicious program can rather
 Frank> easily circumvent Opcode restrictions just by eval'ing some code.

Ah, that's why! This is not so - AFAIU from reading manuals. First of all,
Opcode restricts only future code compilation - so code like:

--
use Opcode; Opcode::opmask_add(Opcode::invert_opset(Opcode::opset(qw(print))));
print "hello!\n" 
--

will print "Hello" anyway. Interestingly, this is a model used now in the
plugin :))))) 
But if you wish to stop the code from calling print(),
the wrapper should be like:
--
use Opcode::opmask_add(Opcode::invert_opset(Opcode::opset(qw(print))));
eval "print qq(Hello!\n)";
---
Thus, we have two important things:
a) - the plugin should not call just "perl filename" - unless no security
wanted. My scheme "perl -MSomeWrapper -e wrapper_init filename"
should be o.k., since SomeWrapper.pm starts first, loads opcodes and then
calls "do filename". SomeWrapper itself may suffer from security
restrictions, but I think this is feasible.
b) - man Opcode says:
 opmask_add (OPSET)
               Adds the supplied opset to the current opmask.
               Note that there is currently no mechanism for
               unmasking ops once they have been masked.  This is
               intentional.
  - so,  malicious program cannot call 'use Opcode; opmask_add(
    full_opset)'. For now I suppose it's quite secure. 

However, the subject of security itself is a tough one, so the 
real opsets and wrappers require thorough design.

 Frank> I guess I need to take another look at Scriptics myself. I'm not
 Frank> certain what you're referring to when you say local-based
 Frank> authorization.  

I can't give you the exact url, dev.scriptics.com is not responding
somewhy, but I found there a faq reference that was like: 
q:-how I'll adjust my security? a:- check the file security.ctl bla bla...
( not sure if it is right filename)

 Frank> I'd be happy to make several schemes available, if we can come up
 Frank> with them.  You certainly don't need tight security if all you ever
 Frank> run is your own programs.  And I have a hard time agreeing with the
 Frank> idea that it's up to the plugin to prevent users from doing
 Frank> dangerously stupid things.  'Microsoft knows best' is not my
 Frank> approach of choice.

Agree.
 Frank> If I understand correctly (and I've only done a very shallow look
 Frank> at this) what Scriptics did was to separate the Tk event loop from
 Frank> the other code and design their widgets to display without having
 Frank> the event loop running.  This allowed them embed a modified
 Frank> interpreter in their plugin and then essentially let Netscape do
 Frank> most of the event handling.

They do quite interesting thing - they invoke Tk loop from timer routine.
Moreover, they run the tk scripts in same process. They gain full access
to NPN, NPP and everything else, but suffer from inability to run
more than one script in the whole netscape session. 
You don't even need a malicious script here - you rather say 
<src embed="..."> twice in one page :))))) - and the whole thing will die.

 Frank> approach with Perl/Tk.  But I was speculating that it might be
 Frank> possible to design a new Perl gui widget set that could be made to
 Frank> work.

You bet :)) - that's I want to do with Prima.

 Frank> I was actively working on a closely related problem and in fact I
 Frank> think it's in the Unix code on sourceforge.  The specific problem I
 Frank> was trying to solve is that when Netscape does a resize, it
 Frank> destroys any embedded windows it has provided.  Unless the Perl
 Frank> application can manage to capture the event and deal with it before
 Frank> the server destroys the window, the Perl application will (usually)
 Frank> die.

Is it really? I was wandering, why NPP_SetWindow restarts the script!
But, I read the plugin guide and it says that NPP_SetWindow is called
( in this case) with two different windows, so there's a moment when both
old and new windows are alive? If it is so, then a blocking notification
to the script ( which responds to window id change) should work. Did you
try that? Or tk can't change the window's parent once created?
And, what way did you signal the perl application?

 Frank> I'll keep my fingers crossed for you.

Hey, it helped! I found right keys for aout, and now it's working 
just fine under freebsd-netscape. Well, some more work to do then ;)

-- 
Sincerely,
	Dmitry