Re: sandboxing
At 07:43 AM 5/8/2001 -0700, Larry Wall wrote: Dan Sugalski writes: : We'd want an alternative opcode running loop for all this, and it could : easily enough check times, as could special opcodes. Long-running codes : could also check at reasonable breakpoints. (Still in trouble with C : extensions, but that's pretty much a guarantee) It's not necessarily an alternative run loop--we need to do something like this anyway for safe signals. What's alternative is that the sandbox gets a periodic mandatory signal telling it to check resource limits. Yeah, but the granularity for safe signals might be too coarse for good resource management. Though we might not want to worry about quite that level of granularity for sandboxes. Brings to mind some of the issues with interrupting timers (alarm for blocking I/O and such), unfortunately. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: sandboxing
Dan Sugalski writes: : We'd want an alternative opcode running loop for all this, and it could : easily enough check times, as could special opcodes. Long-running codes : could also check at reasonable breakpoints. (Still in trouble with C : extensions, but that's pretty much a guarantee) It's not necessarily an alternative run loop--we need to do something like this anyway for safe signals. What's alternative is that the sandbox gets a periodic mandatory signal telling it to check resource limits. Larry
Re: sandboxing
On Thu, May 03, 2001 at 03:53:53PM -0500, David L. Nicol wrote: the larger question remains, is sandboxing something a language should support at all, or is it best left to the OS to provide a solid chroot facility? CPANTS will have to try and clunk a sandbox together and I have no illusions about how difficult this will be. On a sane Unix, yes we have chroot. But what about Windows? MacOS? VMS? EEEK! Not withstanding getting into trying to limit things like sockets, disk usage, etc... Sure, Unix has ulimits, ipchains, quotas, etc... but what about the DumbOS's and the AncientOS's? IMHO that should be the indicator of whether Perl needs to provide a particular sandbox feature. If we leave it up to the OS, how many OS's leave no way (or very difficult ways) to do it. And how radically different are the ones which provide it? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One But unluckily most Germans here are too smart. They all speak good English and won't be able to speak German to me. --Alex Chiu, Immortality Guy
Re: sandboxing
On Fri, May 04, 2001 at 09:20:13AM -0400, Dan Sugalski wrote:
Building a good sandbox with resource limits on a VMS system is trivial. I
expect it may even be easier with IBM's big iron OSes.
I'm sure it is. I'm just worried about having lots of:
if( $^O =~ /VMS/ ) {
do some really scarey (to a Unix user) VMS hacks
}
elsif( $^O =~ /Big Iron/ ) {
do some different really scarey hacks
}
etc...
Obviously this will have to be done at some point, but I'd rather it
was encapsulated somewhere. Either inside Perl or in some core
sandbox/Safe module.
It's less trivial with Unix, but not bad. Beats me on WindowsNT,
though I'd bet it's up to the task.
The single-user OSes are more problematic. I don't know that MacOS (before
OS X) provides the info we need but as of System 7.x it didn't. Nor Win9x,
or AmigaOS. (Though for those we can still track memory usage)
I'd prefer that when we think about the cross-platformness of Perl 6
we keep these troublesome OS's in mind as far as considering what Perl
should leave to itself and what it should leave for the OS to decide.
Luckily the security sandbox features are all implementable from
within perl. It's the resource limitation ones that are trickier,
especially CPU time.
Memory limits we should be able to do, assuming Perl 6 continues to
have its own malloc.
CPU usage is a problem... we could provide two similar, but easier to
implement, features. Throttling (by sticking a tiny little sleep
between each opcode) and limited running (ie. kill yourself if you run
longer than X seconds). The latter we might be able to pull of
externally using SIGALRM, but not all systems have that.
Also things like limiting the number of open filehandles and sockets and
limiting network usage could be done inside perl.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
And Solaris must be destroyed.
-- Peter Miller
Re: sandboxing
Memory limits we should be able to do, assuming Perl 6 continues to have its own malloc. Well... Perl doesn't use it's own malloc *that* widely. E.g. Linux doesn't, since at least 5.005_03. FreeBSD doesn't. OpenBSD doesn't. Darwin doesn't. AIX doesn't. IRIX doesn't. Starting from 5.8.0 Solaris won't (at the behest of Alan Burlison and few others). The reason? Usually it has been the system malloc being (a) faster (I think the BSDs) (b) more robust under multithreading (IRIX). Also starting from 5.8.0 Tru64 or any other naturally 64bitall plaform won't (since the Perl malloc is not 64bitall-clean). CPU usage is a problem... we could provide two similar, but easier to implement, features. Throttling (by sticking a tiny little sleep between each opcode) and limited running (ie. kill yourself if you run longer than X seconds). The latter we might be able to pull of externally using SIGALRM, but not all systems have that. Or setrlimit() for the systems that have that. Also things like limiting the number of open filehandles and sockets and limiting network usage could be done inside perl. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: sandboxing
On Fri, May 04, 2001 at 09:03:05AM -0500, Jarkko Hietaniemi wrote: Memory limits we should be able to do, assuming Perl 6 continues to have its own malloc. Well... Perl doesn't use it's own malloc *that* widely. Who knows what Perl 6 will do internally, but we'll probably have some sort of malloc wrapper at least. Anyhow, if you need to set a certain flag when compiling perl6 to allow certain sandbox features (I can see certain checks necessary being in very hot parts of the code) that should be ok. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One AY! The ground beef, she is burning my groin! http://sluggy.com/d/990105.html
Re: sandboxing
David L. Nicol wrote: In all the discussion of customizing the parser, let us not forget that we also need to be able to limit the parser. O.k., but what you say below isn't about limiting the parser, it's about limiting the VM. is sandboxing something a language should support at all, or is it best left to the OS to provide a solid chroot facility? IMHO this is one of those things that should be kept firmly in the front of our minds as we design the engine. It is yet another area in which we could do right what java got half-right. -- John Porter It's so mysterious, the land of tears.
Re: sandboxing
At 05:22 PM 5/3/2001 -0400, John Porter wrote: David L. Nicol wrote: is sandboxing something a language should support at all, or is it best left to the OS to provide a solid chroot facility? IMHO this is one of those things that should be kept firmly in the front of our minds as we design the engine. It is yet another area in which we could do right what java got half-right. The biggest problem I have with sandboxing is that to do it right is apparently difficult, judging by the number of people that get it wrong. We need to rope in a security expert, I think, for the design. I don't suppose we have one in the house somewhere? Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: sandboxing
From: Dan Sugalski [mailto:[EMAIL PROTECTED]] At 05:22 PM 5/3/2001 -0400, John Porter wrote: David L. Nicol wrote: is sandboxing something a language should support at all, or is it best left to the OS to provide a solid chroot facility? IMHO this is one of those things that should be kept firmly in the front of our minds as we design the engine. It is yet another area in which we could do right what java got half-right. The biggest problem I have with sandboxing is that to do it right is apparently difficult, judging by the number of people that get it wrong. We need to rope in a security expert, I think, for the design. A Language-Based Approach to Security: http://www.cs.cmu.edu/~rwh/papers/langsec/dagstuhl.pdf ResearchIndex is a fun site to explore: http://citeseer.nj.nec.com/volpano98language.html Java influenced papers: http://www.cs.princeton.edu/sip/pub/
Re: sandboxing
The biggest problem I have with sandboxing is that to do it right is apparently difficult, judging by the number of people that get it wrong. We need to rope in a security expert, I think, for the design. I don't suppose we have one in the house somewhere? Where have you gone, Malcolm Beattie? A nation turns its lonely eyes to you. Oooh-ooh-ooh. Er, a republic.
