>The use case that we have in mind is to allow an unprivileged user run a preconfigured container, which configuration is only writable for power users. Ideally the unprivileged user should not be able to meddle with the cgroups or even create new containers.
How I handle this is that my web application. It accepts user input (sanitization + validation) then creates a container on the host machine. The container is equipped with a LAMP stack with sshd running and new keys generated. The user of the container can ssh into their container and meddle away. They can take snap shots before they meddle. I don't really care. I care about if the user can break out of the container. And as long as the kernel is secure, they can't. j On Tue, May 16, 2017 at 8:59 PM, Dr. Todor Dimitrov <[email protected]> wrote: > I guess LXD would not be an option since we are talking about resource > constrained devices. The unprivileged user is actually used only for > namespacing purposes and not for actual logins. The power user starts a > “provisioning/bootstrapping" process as the unprivileged user, which in > turn starts the lxc container and performs some additional tasks, e.g. > monitoring. The bootstrapping process might not be “trusted” in the sense > that it could have bugs, which should not have any adverse effects on the > main functionality of the device. > > Maybe the problem can be re-formulated: is an unprivileged container owned > by an unprivileged user any more safer than an unprivileged container owned > by root? > > Todor > > On 17. May 2017, at 01:38, Fajar A. Nugraha <[email protected]> wrote: > > On Tue, May 16, 2017 at 12:21 PM, Dr. Todor Dimitrov < > [email protected]> wrote: > >> My understanding is that the unprivileged user owning the container can >> still alter the cgroups, right? >> >> > > You should really try lxd. e.g. https://linuxcontainers.org/lxd/try-it/ , > or install it on your own ubuntu server/vm. > > >> The use case that we have in mind is to allow an unprivileged user run a >> preconfigured container, which configuration is only writable for power >> users. Ideally the unprivileged user should not be able to meddle with the >> cgroups or even create new containers. >> >> Is such a scenario feasible to implement using LXC and cgroups? >> > > > That's what lxd does. Sort of. Some options: > - you create an unpriv container (the default in lxd), then give access to > the container (e.g. ssh keys, root pass of the container, etc) to the user. > They will be able to restart the container and install whetever package > they want, but they can't create another container > > - you create an unpriv container with nesting enabled (which is what the > try-me link does). The unpriv user will have a set of limits (e.g. total > disk space, total memory, etc) which they can use to create containers > under it. > > In either way, the container's root user will not be able to alter it's > own cgroup configuration (e.g. /sys/fs/cgroup/memory/ > memory.limit_in_bytes). > > -- > Fajar > _______________________________________________ > lxc-users mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users > > > > _______________________________________________ > lxc-users mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users >
_______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
