On Mon, Jul 31, 2006 at 12:55:04AM +0900, Jun OKAJIMA wrote:
> I have been thinking same idea.
> Meaningful usage, I suppose.
> Basically, Yes.
Sounds good ;)
> The condition the host (=Windows) is threatened is,
> - Attacker gets root of the guest.
> - coLinux has a bug.
> - seccomp or linux has a bug.
> The third condition is same when you are using normal Linux,
> so omit the discussion here.
> The first condition must not happen, if seccomp has no bug
> ( = 3rd cond.)
Indeed, in turn 1st is also the same as normal linux.
> Then, the discussion goes to the second cond.
> The answer is, not sure, but dont care.
> coLinux has many bugs, and it is theoretically possible to
> exploit Windows with the bugs. But, I guess if you are using
> seccomp they are not serios threats. It seems to be difficult that
> exploiting Windows with seccomp bugs.
So you mean that most of the bugs can only be triggered by more
complex syscalls that translates in complex windows calls?
> And there is another concern. Does seccomp has functions to avoid
> DoS attack? For example, running very huge task to stop your
> computer or such.
The ram size of the seccomp task is already handled by the CPUShare
software (mixing the buy order with the sell order with the maximum
ram available according to /proc/meminfo). It's a common problem with
the normal native linux, or did I misunderstand?
The model I would prefer is to boot a livecd, so I could upload a
single livecd and have it run under colinux and other virtualization
solutions as well. That should be feasible.
I wonder if there's a way to detect the version of colinux from the
linux guest, that would allow me in case 2 to block all buggy colinux
versions and to send a meaningful email to all affected users, until
they upgrade their colinux package. That's quite an important feature,
because I could also immediately reject all potentially vulnerable
clients, I already can do that in case of kernel seccomp bugs or in
case of CPUShare client bugs. A /proc/ file would do the trick just