-----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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of > Conduct: http://fedoraproject.org/code-of-conduct > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI4UJEACgkQrlYvE4MpobN+6gCgz6dHVm8kDHFLHJss6vLt7QaT b2cAnRhr3ODzKRz9HUQrspruwAI8Sq7+ =xqk7 -----END PGP SIGNATURE----- _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
