Messages in this thread | | | Date | Thu, 13 Jul 2006 01:44:41 +0200 | From | andrea@cpushare ... | Subject | Re: [2.6 patch] let CONFIG_SECCOMP default to n |
| |
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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |