[clug] Process sandboxing

[Robert Edwards]

On 18/07/11 14:33, jm wrote:
> On 18/07/11 1:42 PM, Robert Brockway wrote:
>>
>> Remember that X-window is network transparent. You can run a GUI app
>> and remote display it - no need to have an X server running on the
>> server running the app.
> The idea I'm thinking of playing with is fully automated, so a gui would
> be a really bad idea.
>
>>> In that case, you might be able to use lxc containers directly; arkose
>>> is basically a GUI frontend for LXC.
>>
>> I'd recommend OpenVZ over LXC. It is true that OpenVZ will eventually
>> go away in favour of LXC but in the mean time OpenVZ has greater
>> stability and features. I expect I'll continue to use OpenVZ for the
>> next 2-3 years and then switch to LXC once it has matured. I don't
>> expect the switch to be painful at all.
>>
>> This is aside from whether containerisation is the right solution for
>> the problem at hand.
>
> I may have mis-spoke about OpenVZ before. I've got to do some more
> digging first. I read a little about LXC on Saturday, but most of the
> stuff I could find was about using it in a manner similar to how you use
> a VM. Tthe material I found on OpenVZ was similar which is why I
> initially concluded it was a poor fit.
>
> The idea I'm thinking of has an architecture where a main program kicks
> off a semi-trusted script supplied by another party. The script then
> uses the main program to provide services. It has no need for anything
> other than: disk to load other modules and store data, a socket to
> communicate with the main program, and, of course, CPU and RAM.
>
> If you have any good refs that talk about using containers for this sort
> of thing please fire away.
>
> Jeff.
>
>

I use OpenVZ a lot and highly recommend it (although I agree with Robert
Brockway that it will eventually yield to LXC when that technology has
matured somewhat).

As for how to do your app, I guess the question to ask is: would it make
sense to run the main app and the third-party script on two different
hosts talking over a network socket from the point of view of the level
of separation you are looking for? If so, then running them in separate
containers under OpenVZ is pretty much just the same.

If you need to be able to dynamically start multiple instances of the
script then things may be more complicated going the container route
with OpenVZ, although I wouldn't go so far as to say it couldn't be done
that way, especially if you can "pre-fork" (pre-create) the container
instances you would need.

Cheers,

Bob Edwards.