Re: [Perlplusplugin-developers] authorization?

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

On 14 Sep 2000, Dmitry Karasik wrote:
Dmitry,
This is excellent discussion!  I'm not certain I understand everything
you're proposing, so I'll have some questions.  But my basic position is
that if you've got an idea you think will work, let's try it.  There are
a number of Perl users who'd like to have the functionality of the
plugin, but the security issues make them wary of using it.  If we can
come up with a really robust way to guarantee that browsing a program
from another site won't damage the local machine, a lot more people will
be interested in using it.

 >	Hi Frank!
 >
 >On 13 Sep 00 at 15:02, "Frank" (Frank Holtry) wrote:
 >
 > Frank> If your library can avoid using the more
 > Frank> dangerous Perl opcodes,then you could definitely use Opcode for
 > Frank> security.
 >
 >I thought that just using Opcode would be enough for a good balance
 >between security and productivity; I thought that eval itself is not
 >a problem, while it contains a legal code. But that's rather a technical

Yes.  I may misunderstand what you're thinking here, so forgive me if I
do.  If there were a way to examine what is being eval'd and only allow
'safe' evals to happen, the problem could be dealt with.  But as I
understand it (and I'm no expert on Perl internals), Opcode doesn't
control the parsing of eval'd code unless that code itself includes a
'use Opcode'.  So a malicious program can rather easily circumvent
Opcode restrictions just by eval'ing some code.

 >side of the implementation. My point is, that cgi authorization is only
 >one of many ways to do things; and from my point of view it's more confusing
 >than helpful. I think that good thing is to implement ( BTW, like

Based on the handful of users who've tried the plugin, I'd tend to agree
that the CGI authorization is confusing.  Most of them have found it to
some degree awkward to set up and get working.  If you have another
idea, lets try it.
 
 >Scriptics that you mentioned does) local security settings; and cgi
 >authorization will be just an extension. Currently we have no such scheme, 

I guess I need to take another look at Scriptics myself. I'm not certain
what you're referring to when you say local-based authorization.  But
I'm certainly willing to try it if it makes sense.

 >and the only possiblilities are either to have cgi-auth or to have none.

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

 >If we agree to change this, the local-based authorization is a good thing
 >IMHO.
 >
 >
 >
 > Frank> Another alternative I looked into and even experimented with a
 > Frank> little is what Scriptics uses for Tcl/Tk.  It's a custom
 > Frank> interpreter embedded in the plugin that only recognizes the 'safe'
 > Frank> subset of Tcl commands.  It also handles events differently to
 > Frank> avoid the problem of two event loops trying to maintain control
 > Frank> simultaneously (one in Netscape, one in the plugin).  You might
 > Frank> find their approach interesting.  You can get the source from
 > Frank> http://dev.scriptics.com/software/plugin.
 >
 >Yes, it is really interesting, but is not applicable to perl, I think.
 >Problems begin when plugin have to handle more than one instance of perl
 > - in one process. When, for example, one task call _exit(), the whole 
 >plugin will die. And, the perl core itself is not thread-safe that way;
 >moreover, such a scheme would require the existence of the event loop -
 >but what if program doesn't have any?

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

As you say, it would take a lot of modification of a Perl interpreter
and of the Tk libraries and modules to use this approach with Perl/Tk.
But I was speculating that it might be possible to design a new Perl
gui widget set that could be made to work.  

 >Of course, running all processes in one is tempting, but I see no way
 >how to implement this model.

 >
 >But the worse thing is yet to come - such an integration will require
 >the awareness of the client process, and it's IPC model. No matter,
 >tcl or perl-tk it will be using, the code base have to be altered heavily.
 >That doesn't matter when you're running only external windows, with no
 >communication to the browser - but this is not interesting! I succeed
 >integrating perl widgets into navigator window, but I want more - page
 >and content interactions, and maybe java. 

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

In the code that's on CPAN, we punted.  We used a facility within the
plugin to restart the Perl application after a resize.  This is ok for
applications that only want to display pretty pictures, but for anything
trying to display the results of serious processing it's disastrous.

So, I was trying to capture the X-window events as they propagated
through the heirarchy and let the Perl application take some action to
preserve it's state.  I got this working about 95% of the time, but it's
always a race between the X-server trying to destroy and cleanup, and
the Perl application (which runs at a lower priority) trying to catch
and respond to the event.  Sometimes, the server wins.  Maybe, with
careful design of the application, I could work around the remaining
instances, but it would certainly be better if Netscape were better
behaved.

 >
 >I am now trying to make the plugin accepting external messages inside
 >it's internal window event handler - so it could also handle external 
 >requests to NPN_XXX routines, which - note! - aren't thread-safe also.

If you manage to solve this problem without serious changes to Netscape
itself, my hat's off to you!  Mozilla appears to have added some
additional NPN_XXX routines to make this a little easier, but this seems
to me to be the most serious weakness in the Netscape plugin model.  It
doesn't provide enough communication between the plugin and the browser,
especially FROM the plugin TO the browser.

 >From the side of a perl program, its own event loop will be listening
 >to the plugin messages, and the exact protocol should be system-specific. 
 >But that is a bad thing, because you have to hack tk's event loop code - 
 >if you need more than just an embedded widget, of course.
 >

My original need for the plugin was to enable launching of Source
Configuration Management tools from a web page.  Displaying nice-looking
widgets isn't quite enough by itself to meet the need.

 >BTW - I still can't compile the plugin under freebsd; right now my machine
 >is busy compiling mozilla port - maybe it will work that way?
 >

I'll keep my fingers crossed for you.

 >


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