Re: [Lxc-users] FUSE and capabilities
TWB == Trent W Buck t...@cybersource.com.au writes: TWB I suppose if I had to support desktop wank, I would set up a TWB udev rule on the host to mount removable devices in TWB /media/VOL ID, and then rbind-mount /media into the TWB container(s). This might be a good idea for some systems, but it wouldn't work well for things like formatting, burning or using FUSE. Perhaps the proper solution would be to add a new capability for secure mounts to the kernel. The question is how much damage can be done in theory to the host and other containers when a container is given the CAP_SYS_ADMIN capability, assuming lxc.cgroup.devices are set properly? I don't care much about DoS problems as those can happen with almost any non-paranoid setup. But can CAP_SYS_ADMIN significantly increase risk of compromising the host or other containers? -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
[Lxc-users] FUSE and capabilities
I tried to use FUSE/EncFS in a container on a Debian 6.0 machine and I've found I have to enable CAP_SYS_ADMIN in order to make it work. Without it, permission error is reported on encfs invocation (and yes, I've got /dev/fuse enabled in lxc.cgroup.devices.allow, it wouldn't work without it even with CAP_SYS_ADMIN set). Do I have to enable CAP_SYS_ADMIN to allow any mount in a container or is there a way to allow user mounts (such as FUSE or USB flash mounts) without giving such a wide permission to the container? -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] FUSE and capabilities
On 02/14/2011 04:41 PM, Milan Zamazal wrote: I tried to use FUSE/EncFS in a container on a Debian 6.0 machine and I've found I have to enable CAP_SYS_ADMIN in order to make it work. Without it, permission error is reported on encfs invocation (and yes, I've got /dev/fuse enabled in lxc.cgroup.devices.allow, it wouldn't work without it even with CAP_SYS_ADMIN set). Do I have to enable CAP_SYS_ADMIN to allow any mount in a container or is there a way to allow user mounts (such as FUSE or USB flash mounts) without giving such a wide permission to the container? I don't think so. The 'mount' syscall checks the CAP_SYS_ADMIN, in all the cases, host or container. AFAIR, the user mountable points are handled by the mount command wrt the fstab file and the 'user/users' keyword. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] FUSE and capabilities
Milan Zamazal p...@zamazal.org writes: I tried to use FUSE/EncFS in a container on a Debian 6.0 machine and I've found I have to enable CAP_SYS_ADMIN in order to make it work. Without it, permission error is reported on encfs invocation (and yes, I've got /dev/fuse enabled in lxc.cgroup.devices.allow, it wouldn't work without it even with CAP_SYS_ADMIN set). Do I have to enable CAP_SYS_ADMIN to allow any mount in a container or is there a way to allow user mounts (such as FUSE or USB flash mounts) without giving such a wide permission to the container? I think current best practice is not to give the container mount privileges; for static mounts you can create lxc.mount entries in the lxc .conf; for dynamic mounts there isn't any sane solution AFAICT. I suppose if I had to support desktop wank, I would set up a udev rule on the host to mount removable devices in /media/VOL ID, and then rbind-mount /media into the container(s). I can't think of a way to handle mounting offhand, so I'd mount them -osync to reduce data loss. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
