Re: [2.6 patch] let CONFIG_SECCOMP default to n

[andrea@cpushare.com]

On Wed, Jul 12, 2006 at 11:02:56PM +0100, Alan Cox wrote:
> Actually measuring time through the network is extremely doable given
> enough samples as is communication through delay perturbation. A good
> viterbi encoder/decoder will fish a signal out of very high noise. Yes
> you pay a lot in data rate at that point but it works.

Currently the bandwidth is free, I'll charge for the transaction
associated bandwidth only if I'm forced to (which would happen quickly
if people starts doing the above ;).

The way the current transactions are running as we speak, is not like
in a full peer to peer system. It's half peer to peer, a trusted node
always sits in between buyer and seller. I need this for a multitude
of reasons (I could offload the middle node in a p3p system that is
reliable as long as only 1 of the 3 is malicious but it's certainly
more secure if the node in the middle is fully trusted so I'll try to
avoid that). So if you are right, my trusted node will simply add
/dev/urandom delay as needed before forwarding any packet, to prevent
any meaningful measurement. Any network side channel can be solved in
a few liner patch and very quickly.

Theoretically speaking everything is possible, but pratically speaking
I will defer any further thought about this 10 years in the future
because I think it's impossible to measure any signal with nanosecond
frequency, over a connection with millisecond resolution passing
through a randomization of tcp/ip kernel code, slowdown of the python
interpreter and kernel pipes until it finally reaches the seccomp
bytecode and then same way backwards. (plus virtualization on vista)

I rate the network side channel even less probable than the TSC one
(which is purely theoretical too like Andi can certainly confirm).

> Anyway at the point you pass the bytecode through a processing filter
> you don't need SECCOMP because your filter can remove any syscall
> attempts. 

Even if I wanted to run the filtered (but originally untrusted)
bytecode out of any jail, I need the NX bit to do that, and I don't
have it in a large part of the (currently tiny) userbase. In the
previous email I wasn't accurate saying self modifying code is only
possible on the stack, obviously it's possibly in the heap too, so not
even the non-executable-stack patches could help. SECCOMP is the only
feasible basic mode to cover all systems >=i686 (I don't support i586
and lower because I think it's not worth the bandwidth they would
generate, and if I'm wrong I can add them later, ia64 is also not
supported and that has higher prio if something).

Security is about having tons of things to break before you gain ring
0 privilege. It'd be totally wrong in security terms to remove
zerocost SECCOMP (or trusted-xen) just because you added a further
security measure on top of seccomp (or xen). It's like leaving the
door of your apartment open just because you enabled the security
alarm (you want to do both don't you?).

The more security you have the better, especially when it's zero cost
like seccomp.

Furthermore the filter would need to know about all archs and
bytecodes in the world, arch details and all possible ways to enter
kernel, it would need to be maintained out of sync with the kernel
development and it would be of an huge complexity compared to the few
liner seccomp patch (all high risk stuff compared to SECCOMP).