Hi Daniel! On Mon, Oct 4, 2010 at 9:51 PM, Daniel Lezcano <daniel.lezc...@free.fr> wrote: > On 10/04/2010 06:18 PM, richard -rw- weinberger wrote: >> >> On Sun, Oct 3, 2010 at 9:01 PM, richard -rw- weinberger >> <richard.weinber...@gmail.com> wrote: >> >>> >>> I'm using lxc to run a few virtual private servers. >>> What capabilities are harmful and should be dropped using "lxc.cap.drop"? >>> >> >> Is my question too trivial or too stupid? ;) >> > > hum, not trivial at all :) > > I am not sure there is a default set of capabilities to be dropped. > Certainly some should be dropped like CAP_SYS_MODULE but others will depend > on what the user expect to do with the container and what scripts will be > run inside the container. > > We have certainly think about the root user inside a container, is it secure > ? IMO, until the user namespace is not complete, it is not secure.
I thought the user namespace is complete. What is missing? >> Here what i know so far: >> >> CAP_AUDIT_CONTROL: >> should be dropped >> CAP_AUDIT_WRITE: >> should be dropped Update: To run openSUSE within lxc we need both CAP_AUDIT_CONTROL and CAP_AUDIT_WRITE. I think pam uses libaudit. >> CAP_CHOWN: >> is ok >> CAP_DAC_OVERRIDE: >> is ok >> CAP_DAC_READ_SEARCH >> is ok >> CAP_FOWNER >> is ok >> CAP_FSETID >> is ok >> CAP_IPC_LOCK >> is ok >> CAP_IPC_OWNER >> is ok >> CAP_KILL >> is ok >> CAP_LEASE >> is ok >> CAP_LINUX_IMMUTABLE >> is ok >> CAP_MAC_ADMIN >> should be dropped >> CAP_MAC_OVERRIDE >> should be dropped >> CAP_MKNOD >> should be dropped >> CAP_NET_ADMIN >> is ok >> CAP_NET_BIND_SERVICE >> is ok >> CAP_NET_BROADCAST >> is ok >> CAP_NET_RAW >> ok? >> > > yes for the ping command for example. Are you sure? Within my openSUSE guest I can use ping without CAP_NET_RAW. >> >> CAP_SETGID >> is ok >> CAP_SETFCAP >> should be dropped >> CAP_SETPCAP >> should be dropped >> CAP_SETUID >> is ok >> CAP_SYS_ADMIN >> should be dropped >> > > The init process (upstart version) will need this because it mounts > internally /proc and /sys. > Some other services will need it like automount. IMHO CAP_SYS_ADMIN is a no-go. A jailed root would be able to mount the cgroup filesystem -> game over. >> >> CAP_SYS_BOOT >> should be dropped >> > > Always dropped today in the lxc-start code. > >> CAP_SYS_CHROOT >> should be dropped Update: sshd needs chroot(). Is it safe to allow it? >> CAP_SYS_MODULE >> should be dropped >> CAP_SYS_NICE >> should be dropped >> > > The cgroup scheduler will protect the host and the other containers from an > abusive nice and the cpuset will prevent unauthorized affinity. So it is > safe to keep it I guess. > >> CAP_SYS_PACCT >> should be dropped >> CAP_SYS_PTRACE >> is ok >> CAP_SYS_RAWIO >> should be dropped >> CAP_SYS_RESOURCE >> should be dropped >> CAP_SYS_TIME >> should be dropped >> > > yes and ensure /dev/rtc is read-only and protected with the cgroup devices > whitelist. > >> CAP_SYS_TTY_CONFIG >> should be dropped >> > > I am not sure, won't getty need it ? You are right. We need it. :-) Thanks so far! //richard ------------------------------------------------------------------------------ Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
