Re: [Perlplusplugin-developers] authorization?

[Frank H. <fh...@av...>]

On 15 Sep 2000, Dmitry Karasik wrote:

 >	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:
 >

I think you're right.  I re-read the Opcode man page, tried your code and then
tested some of my applications with the plugin authorization set to 1.  It turns
out that the opcode that gets trapped is buried somewhere in the bowels of a 
widget and is part of a block of eval'd code.  So, there's definitely a hole,
since code that doesn't do an eval could execute pretty much anything else it wants.

There was a discussion of this issue on p5p almost two years ago.  I'm going to
have to re-read it, because I was fairly certain that the statements I made 
earlier were a paraphrase of that.  I hope I simply misunderstood, but
I know I've heard similar comments regarding eval at the O'Reilly conferences.

 >--
 >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.

It sounds feasible to me.

 >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.
 >

Do you think more needs to be done with opsets than what is currently in np_perl.h?
And you say 'wrappers' as if more than one might be needed?

 > 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.
 >

Yes. There's a lot wrong with their plugin, not least of which is that the
security is so strong (as it is in Java, too, IMHO) that it's difficult to
accomplish the sort of things I'm trying to do.  The problems really are
due to their having built the plugin after the fact, so to speak.  They
tried to compensate for insecure widgets by compromising their functionality.

But having an embedded interpreter so the application runs as part of the
Netscape process is something I'd really like to have.  I don't believe it
can be done with Tk because of the event loop.  But if the Prima widgets are
designed from the beginning to work with both a plugin and an external 
event loop, I think it would be a dynamite tool.

 > 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

should have said: the current solution is in the sourceforge code.  

 > 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

NPP_SetWindow( NPP instance, NPWindow * window) is what I have for the
function, which only has one window pointer.  It's possible the API changed
so that both the about-to-be-destroyed window and the newly created window
are available.  Is yours different?  This is an area where having an embedded
application would greatly simplify the problem.  As it is, what I've been 
doing is to query the X-server in the Perl code to construct the window 
heirarchy, then capture the ResizeRequest event by setting a mask on various
windows, then reparenting the Tk wiget outside Netscape until the resize is
completed.  All very awkward and subject to race problems as I noted before.

 >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?

Tk 800.010 and later can, I believe.  Tk 400.xxx could not, to my
knowlege, although it is possible to force reparenting with
X11::protocol methods.

 >And, what way did you signal the perl application?

This is really the crux of the problem.  I haven't found a good way to signal
the application.  The plugin itself is notified too late to provide a 
useful signal to the Perl application.  Theoretically, the X-server does it,
but perl executes slowly enough that the server has time to destroy the window
before the perl code can capture and respond to the resize event.  Requesting
notification on windows far enough down in the heirarchy can increase the odds
that perl will be able to react before the server does, but it never quite
reaches certainty.

I looked for a spot in the plugin's calling sequence where I might be able
to do the same sort of thing.  But because the plugin functions are called,
you might say, at the whim of Netscape, there didn't appear to me to be a
way to set up the proper masks and signal the perl application.  This is
something that could be looked at again, though, now that I have a somewhat
better grasp of how X-events work.

 >
 > 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 ;)

This is great news!  

 >
 >

-- 
-------------------------------------------------------------------------------
| Frank Holtry           | "If you have the right attitude, interesting       |
| fh...@av...      |  problems will find you."                          |
|                        |                            Eric S. Raymond         |
-------------------------------------------------------------------------------