On 01.08.2014 07:21, Trevor Jay wrote:
On Thu, Jul 31, 2014 at 10:38:59PM +0200, Stef Walter wrote:
> I've heard this concept slung around, but never saw it in real
> life. What does a Docker privileged container look like and how
> does it work? Any documentation? A trivial google search doesn't
> seem to turn up anything definitive.
>
"Normal" containers run with a munged network (i.e. 172.* address),
dropped kernel capabilities, and under a limited SELinux security
context (i.e. system_u:system_r:svirt_lxc_net_t:s0:c712,c869). Docker
containers started with the "--privileged" option still run with a
munged network but have fewer (maybe even no, I'd have to check the
source) kernel capabilties dropped and run under a more lenient
SELinux. The more lenient context is something like:
system_u:system_r:docker_t:s0. I can't remember exactly off the top
of my head.
To give a concrete example: normal containers probably can't access
the /dev/ pseudo-filesystem the way Cockpit (I assume) needs to. I
would expect that a "--privileged" container could.
Interesting.
Cockpit needs to do stuff like this in the main host:
* Access the file-system (eg: journal, and much more)
* Access the DBus system bus and activate things there, like udisksd,
NetworkManager, systemd parts ... also some of cockpit's dependencies
like storaged are activated on the main system bus.
* Read access to cgroup tree
* Connect to docker socket
* Run host commands like shutdown.
* Authenticate against host PAM stack and user database
The actual networking in use for running Cockpit isn't *that* important,
as we would connect out to NetworkManager anyway to do configuration.
But we would need to be able to ask the kernel about the throughput of
the various interfaces.
Also when you connect out remotely to have Cockpit look at
multiple-machines, it does so via SSH. So we would need to somehow add
that SSH subprocess into an appropriate privileged container. Or perhaps
stop using SSH for this purpose ...
In addition cockpit starts a real PAM/systemd/audit session once logged
in, and the logged in processes run under unconfined_t selinux context
(similar as you would for a shell). So the semantics of this would need
to be figured out.
Lots of work. Would be interested in the results if you end up playing
with this.
Is there would be a way to *only* add a file system namespace containing
the entire system file system + the cockpit data/binaries bind mounted
in. This would still run into a few problems above, but many of them
would just work.
Stef