"Try it now"

[spir]

On 04/14/2011 02:51 AM, Adam D. Ruppe wrote:
> Andrej Mitrovic wrote:
>> I've always wondered.. how do you detect malicious D code?
>
> It doesn't. What it does is use the ulimit feature in linux to
> limit the resources available to each process so they can't do
> anything.
>
> Try it:
>
> int[] a;
> a.length = 5_000_000; // "Memory allocation failed"
>
>
> for(;;) {} // forcibly terminated by the kernel after ~8 seconds
>
> auto f = File("cool_a_file", "wt");
> for(int a = 0; a<  10_000; a++)
>    f.writefln("%d", a);
>
> // reports success, but the file is actually only 8 kb:
>
> # ls -l cool_a_file
> -rw-r--r-- 1 apache apache 8192 2011-04-13 19:22 cool_a_file
>
> # tail -n 2 cool_a_file
> 1859
> 18 // you can see it got forcibly cut off
>
> There's file permissions in place that you shouldn't be able to
> access anything on there, except reading the system files. It's
> a stock Linux install - nothing to see there. Writing is limited
> to the scratchspace directory, which isn't public to the web or
> anything.
>
>
> What if you tried to fill the disk by creating files in a loop?
> You actually can do that, until you're killed for either running
> for too long or hitting the scratchspace's disk quota. I don't
> know how to prevent that except for disabling files altogether,
> and I think that would diminish the usefulness a little. File
> examples are fun too.
>
> (note if you do fill the scratchspace, it's not a big deal. It's
> garbage collected in a way - the compile helper catches disk
> full exceptions and cleans it out when needed. Still, don't do that.)
>
> Access to the network is firewalled too. You can play on localhost
> to a degree, but anything to and from the outside world is filtered.
> Shouldn't be possible to run a spambot on it, since nothing on
> that machine is allowed to call out, not even root.
>
>
> Keep in mind that DMD lives under similar constraints. If it
> goes wild, it will be killed by the kernel before too long too,
> and can't make files bigger than about a megabyte. It's limited
> to 256 MB of RAM.
>
>
> This describes the limits in the operating system. There's
> additional limits at the VM level, so even if you got root, you
> couldn't do much with it. This is why it's also on a separate
> domain name than anything else too - if you put a web exploit
> on it, there's nothing much to do with that either. Like it's
> name says, it's all completely expendable info.
>
> Finally, I snapshotted the VM in a known good state. If you do
> root the box, I can always revert to that too (considering writing
> a program to automatically revert each day actually, but haven't
> gotten around to it yet).
>
> Of course, worst case scenario is I just pull the plug on it. I
> hope it never comes to that, but some people are assholes, so
> if I have to, it's an option.
>
>
> Anyway, as you can see, I tried to cover all my bases with enough
> fallback plans that I'm not concerned about malicious code at all.

We'd need a sandbox.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com