Jarkko Hietaniemi <[EMAIL PROTECTED]> chipped in:
> On Fri, Feb 23, 2001 at 10:26:14AM -0500, Dan Sugalski wrote:
> > At 07:12 AM 2/23/2001 -0500, wiz wrote:
> > >Just curious, has anyone ever had any discussion regarding a
'security-aware'
> > >Perl model? Some issues have recently ended up on my desk, and I been
having
> > >some preliminary thoughts on the subject. It would be nice to be able to
set
> > >some rules for what Perl is allowed to do on a server without having to
worry
> > >about the OS-level stuff. Sort-of like Apache does now. Anyone heard of
> > >anything like this?
> >
> > There was a little talk about redoing Safe, but that was about it. Got any
> > ideas on the subject?
>
> I have :-) I think limiting access Safe-like, that is, having bitmasks
> on what ops one can do is good, but nowhere near enough, or even that
> useful, and the more ops you allow, the more difficult it becomes to
> control what people might be able to do by combining those ops in
> creative and unexpected ways. What's more important is the Outside of
> the box, the filesystems and the os: what filesystems one can access,
> how much memory one can access, how much CPU one can burn, how many
> files can one open. In short, I'm more concerned about denial of
> service attacks/leaks than access control/permissions.
I have too :-))
I'm thinking from the point of view of an ISP who wants to offer his
customers mod_perl access on an Apache server, without customers being
able to write nasty code that hacks the system or DOS's it.
In the forthcoming threaded Apache 2, Doug's plan is (I believe) to have
a pool of perl interpreters, and each time an Apache thread happens to need
to execute some Perl, grabs a spare intepreter and gets it to run the code.
>From this perspective, I'd like to see an optional 'security struct'
that can be passed to an interpter thread each time it's invoked, listing
potential restrictions in all sorts of areas, such as:
* filesystem access
* access to modules (both loading and execution) - expecially XSUBS
* resources such as memory, CPU, file-handles, sockets etc
* anthing else you could possibly think of.
It would be the responsibility of the various Perl subsystems (eg perlIO)
to check whether there any listed restirctions, and enforce them.
Perl 6 would have to built from the ground up with a security model
such as this in mind for it to stand any chance of being secure.
As to how this would work in practice, I havent a clue.... :-)
