Re: [-mm patch] seccomp: don't say it was more or less mandatory

[Ingo Molnar <mingo@elte.hu>]

* Andrea Arcangeli <andrea@cpushare.com> wrote:

> > obviously the irq and sys_read/sys_write code is way too complex to be
> > mathematically provable in the near future.
> 
> Math provable is irrelevant with real software world since nobody has
> enough resources to demonstrate math correctness.

(this is becoming tangential, but i'd not be as brave to suggest that
formal provability of real software is irrelevant. It's not feasible
today and probably not feasible in the near future. What tomorrow brings
we cannot know.)

> > sorry, but if an attacker can cause arbitrary signals to be sent to your
> > secure application (and the signals pass the security checks!) then you
> > have much bigger problems!
> 
> It's not the attacker that sends the signal! It's a buggy application
> coming from the CDs, like a videogame hitting a bug.

well, for an attack to become possible, it's the attacker that has to be
able to trigger it. By your logic i could say: 'many people use empty
passwords for root, so it could easily happen that a seccomp box gets
compromised that way'. The fact that sending SIGCONT to the seccomp
application _seems_ to be more related to the security of the ptrace
solution does not make it any more relevant in reality than the root
password issue. (But i guess after many years i should be wiser not to
get into such arguments with you.) And i've yet to see applications
sending spurious SIGCONT's to each other 'by accident'.

OTOH, i accept your point that a 'no way back' kernel-enforced kind of
sandbox (which seccomp provides and ptrace doesnt) is a useful concept.

	Ingo