On 14/03/2017 14:02, Daniel P. Berrange wrote: >>> Can you give an example of such a list? >> >> Well, anything that makes "-sandbox on" more than security theater... I >> would consider it a necessary evil, not a good thing to have such a list. >> >> Due to NO_NEW_PRIVS, I think non-migration fork/exec should be on the >> list, but hopefully nothing else. > > The current semantics of '-sandbox on' are that it is documented to not > break any valid QEMU features. By blocking fork/exec, we make a semantic > change to the existing behaviour of '-sandbox on'.
I don't propose to block fork/exec. I propose not to whitelist setuid, as is the case now too. It wouldn't be backwards-incompatible. > So any application > which has been using '-sandbox on' historically, is at risk of being > broken when upgrading to QEMU 2.10. It would force the application to > generate a different CLI for new QEMU - ie to avoid being broken they > would have to now add elevateprivs=allow, spawn=allow. I think we have > to maintain semantic compat with existing usage, which means that > '-sandbox on' has to remain security theatre. > > So if we want a default config to be more restrictive, then I think you > realistically have to turn the default parameter into a tri-state > instead of bool, ie allow '-sandbox default' as an alternative to > '-sandbox on' that was slightly stronger by blocking fork/exec. Or just print a warning that "-sandbox on" is useless. I guess that would be okay too if we want to be "stronger" than backwards-compatible. Paolo
