-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/16/2013 04:57 PM, Colin Walters wrote:
On Wed, 2013-09-11 at 12:01 -0400, Matthew Miller wrote:
So, idea one is to make something like CoreOS (http://coreos.com/): a lightweight distribution made for running containers on top of. We wouldn't attempt to be _as_ lightweight as CoreOS (for that, there's CoreOS), but aim to be small while still providing key features like SELinux.
How SELinux would work in a coreos/container deployment setup is an interesting question. One could imagine docker containers coming with policy modules, but that ends up tying them to a specific host version, which is kind of against the point of containers.
More realistically I think one would have a relatively permissive domain (generic_container_t), and use something like MCS labels to restrict the flow of information between containers and the host.
Currently that is what we do with virt-sandbox containers. svirt_lxc_net_t and svirt_qemu_net_t is very loose, Full Network, Full Capabilities, Read/Execute everything in /usr and most of /etc, no access to content in /root, /home, /var (We bind mount containers content over /root, /home, and /var) And separate them from MCS. They are only allowed to write to svirt_sandbox_file_t.
I have setup the policy to allow policy writers to create limited network privs container domains, fairly easily. Perhaps we should do the same for capabilities.
One concept I have built for OpenShift is the idea of an Admin of a container versus the application within the container. So a user joining a container might have full access to all file types owned by the container, but the applicagtion/service within the container would only be allowed to write to the svirt_sandbox_file_rw_t content and read/exec svirt_sandbox_file_t content.
Perhaps this could be built with Colin Walter's OSTree (see https://wiki.gnome.org/OSTree) for atomic updates.
To follow up on this, I have been working slowly on this tool called "yum-ostree" which is designed to capture packages as OSTree commits. At the moment it's just a lame python script, but it's nearly to the point of being useful. I'll post to the generic fedora-devel-list when it's ready.
As far as OSTree compared to CoreOS; the biggest difference is that the CoreOS updater mandates a particular filesystem chosen on the build server, because it sends block-level diffs. OSTree operates at the filesystem layer (like rsync), and this allows more flexibility. (At the moment though, OSTree is significantly less efficient on the network side).
_______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct