Future directions for Fedora Cloud

[Daniel J Walsh]

-----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 at lists.fedoraproject.org 
> 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-----