mirror of
https://git.proxmox.com/git/mirror_lxc
synced 2025-08-05 15:27:31 +00:00
![]() When a container starts up, lxc sets up the container's inital fstree by doing a bunch of mounting, guided by the container configuration file. The container config is owned by the admin or user on the host, so we do not try to guard against bad entries. However, since the mount target is in the container, it's possible that the container admin could divert the mount with symbolic links. This could bypass proper container startup (i.e. confinement of a root-owned container by the restrictive apparmor policy, by diverting the required write to /proc/self/attr/current), or bypass the (path-based) apparmor policy by diverting, say, /proc to /mnt in the container. To prevent this, 1. do not allow mounts to paths containing symbolic links 2. do not allow bind mounts from relative paths containing symbolic links. Details: Define safe_mount which ensures that the container has not inserted any symbolic links into any mount targets for mounts to be done during container setup. The host's mount path may contain symbolic links. As it is under the control of the administrator, that's ok. So safe_mount begins the check for symbolic links after the rootfs->mount, by opening that directory. It opens each directory along the path using openat() relative to the parent directory using O_NOFOLLOW. When the target is reached, it mounts onto /proc/self/fd/<targetfd>. Use safe_mount() in mount_entry(), when mounting container proc, and when needed. In particular, safe_mount() need not be used in any case where: 1. the mount is done in the container's namespace 2. the mount is for the container's rootfs 3. the mount is relative to a tmpfs or proc/sysfs which we have just safe_mount()ed ourselves Since we were using proc/net as a temporary placeholder for /proc/sys/net during container startup, and proc/net is a symbolic link, use proc/tty instead. Update the lxc.container.conf manpage with details about the new restrictions. Finally, add a testcase to test some symbolic link possibilities. Reported-by: Roman Fiedler Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com> Acked-by: Stéphane Graber <stgraber@ubuntu.com> |
||
---|---|---|
config | ||
doc | ||
hooks | ||
src | ||
templates | ||
.gitignore | ||
.travis.yml | ||
AUTHORS | ||
autogen.sh | ||
configure.ac | ||
CONTRIBUTING | ||
COPYING | ||
INSTALL | ||
lxc.pc.in | ||
lxc.spec.in | ||
MAINTAINERS | ||
Makefile.am | ||
NEWS | ||
README |
Please see the COPYING file for details on copying and usage. Please refer to the INSTALL file for instructions on how to build. What is lxc: The container technology is actively being pushed into the mainstream linux kernel. It provides the resource management through the control groups aka process containers and resource isolation through the namespaces. The linux containers, lxc, aims to use these new functionalities to pro- vide a userspace container object which provides full resource isolation and resource control for an application or a system. The first objective of this project is to make the life easier for the ker- nel developers involved in the containers project and especially to con- tinue working on the Checkpoint/Restart new features. The lxc is small enough to easily manage a container with simple command lines and complete enough to be used for other purposes. Using lxc: Refer the lxc* man pages (generated from doc/* files) Downloading the current source code: Source for the latest released version can always be downloaded from http://linuxcontainers.org/downloads/ You can browse the up to the minute source code and change history online. http://github.com/lxc/lxc For detailed build instruction refer to INSTALL and man lxc man page but a short command line should work: ./autogen.sh && ./configure && make && sudo make install preceded by ./autogen.sh if configure do not exist yet. Troubleshooting: If you get an error message at the autogen.sh or configure stage, make sure you have, autoconf, automake, pkg-config, make and gcc installed on your machine. The configure script will usually give you hints as to what you are missing, looking for those in your package manager will usually give you the package that you need to install. Also pay a close attention to the feature summary showed at the end of the configure run, features are automatically enabled/disabled based on whether the needed development packages are installed on your machine. If you want a feature but don't know what to install, force it with --enable-<feature> and look at the error message from configure. Getting help: when you find you need help, you can check out one of the two lxc mailing list archives and register if interested: http://lists.linuxcontainers.org/listinfo/lxc-devel http://lists.linuxcontainers.org/listinfo/lxc-users Portability: lxc is still in development, so the command syntax and the API can change. The version 1.0.0 will be the frozen version. lxc is developed and tested on Linux since kernel mainline version 2.6.27 (without network) and 2.6.29 with network isolation. It's compiled with gcc, and should work on most architectures as long as the required kernel features are available. This includes (but isn't limited to): i686, x86_64, ppc, ppc64, S390, armel and armhf. AUTHOR Daniel Lezcano <daniel.lezcano@free.fr> Seccomp with LXC ---------------- To restrict a container with seccomp, you must specify a profile which is basically a whitelist of system calls it may execute. In the container config file, add a line like lxc.seccomp = /var/lib/lxc/q1/seccomp.full I created a usable (but basically worthless) seccomp.full file using cat > seccomp.full << EOF 1 whitelist EOF for i in `seq 0 300`; do echo $i >> seccomp.full done for i in `seq 1024 1079`; do echo $i >> seccomp.full done -- Serge Hallyn <serge.hallyn@ubuntu.com> Fri, 27 Jul 2012 15:47:02 +0600