On Thu, Sep 16, 2010 at 01:50:46PM +0100, Daniel P. Berrange wrote:
The distinction is between what is possible, and what is recommended to do. Even with the supervisor & QEMU having separate SELinux contexts, it is still desirable to lock down the supervisor to only be able to access the VM lease file & only its own QEMU pid. So while we could write policy such that a supervisor can talk to a central lock daemon, it is preferrable for the lock supervisor to be self contained.
The other point I make is that SElinux is the main security driver today, but others will come along in the future. A container based security driver will almost certainly completely isolate the spawned processes with no option to talk to a central lock daemon. There would be separate filesystem namespace, PID namespace, network namespace per VM - in essence each process would see its own isolated OS with only QEMU & the optional lock supervisor running in it.
Could containers make isolation exceptions for - shared storage devices? - shared /var/run/sync_manager/watchdog/ so that the system watchdog could monitor all sync_manager instances? Dave