On Tue, Jun 23, 2009 at 07:45:34PM -0700, Casey Schaufler wrote: > Serge E. Hallyn wrote: > > Quoting Daniel P. Berrange (berrange@xxxxxxxxxx): > > > >> This patch updates the LXC driver to make use of libcap-ng for managing > >> process capabilities. Previously Ryota Ozaki had provided code to remove > >> the CAP_BOOT capabilities inside the container, preventing host reboots. > >> In addition to that one, I believe we should be removing ability to > >> load kernel modules, change the system clock and changing audit/MAC. > >> So this patch also clears the following: > >> > >> CAP_SYS_MODULE, /* No kernel module loading */ > >> CAP_SYS_TIME, /* No changing the clock */ > >> CAP_AUDIT_CONTROL, /* No messing with auditing */ > >> CAP_AUDIT_WRITE, /* No messing with auditing */ > >> CAP_MAC_ADMIN, /* No messing with LSM */ > >> CAP_MAC_OVERRIDE, /* No messing with LSM */ > >> > > What is going to run inside your container? Turning off the MAC > capabilities can seriously limit the programs that can run inside > it. If you can't drop CAP_DAC_OVERRIDE or CAP_KILL it's unlikely > that it makes sense to drop CAP_MAC_OVERRIDE. Similarly, if you > can't drop CAP_FOWNER or CAP_CHOWN you'll probably be ill advised > to forgo CAP_MAC_ADMIN. The containers are all run with CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWUSER|CLONE_NEWNET and each has a private filesystem setup. Thus there is no need to restrict things like CAP_FOWNER/CHOWN, since the only files the container process can access are those within its private FS. Likewise CAP_KILL is ok, since CLONE_NEWPID ensures the container can only see its own processes, and none of those from the host. Given those CLONE_* flags being set, is it safe to allow a container to have CAP_MAC_ADMIN/CAP_MAC_OVERRIDE capabilities ? I was concerned that those capabilities may still allow the container to perform changes that would impact MAC settings for the host as a hole, and not be confined. If that's not the case, then I will change the patch to not clear those capabilieis. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list