grsecurity forums

Hi all,

Whish you a less buged 2012 year !

Like it's wrotten in the title, I would like to make my LXC container work on a GRSEC patched Kernel (I use version 2.6.32.52).
Before posting here I've been looking around on the net to see if someone had found a solution to this, but all I found was'nt working for me...

I patched my Debian 2.6.32.52 kernel with grsec and since then when I start lxc (lxc-start -n container) I got the following error message:

Code: Select all

lxc-start: Operation not permitted - failed to umount 'dev/pts'
lxc-start: failed to setup the new pts instance
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'HTTP'
lxc-start: Device or resource busy - failed to remove cgroup '/cgroup/HTTP'


So I tried to compile the Kernel:
disabling RBAC
disabling CONFIG_PAX_KERNEXEC
enabling CONFIG_DEVPTS_MULTIPLE_INSTANCES

But I still have the same problems.

Today I noticed that I could see more being directly working on the physical machine. I can see a few messages like:

Code: Select all

[65569.795891] grsec: use of CAP_SYS_ADMIN in chroot denied for /usr/bin/lc-start [lxc-start:2513] uid/euid:0/0 gid/egid:0:0, parent /usr/bin/lxc-start[lxc-start:2507] uid/euid:0/0 gid/egid:0/0


I may need to allow CAP_SYS_ADMIN to lxc-start or something like that but because I'm not a Kernel expert I would really appreciate a bit help or even some advices...

Thanks for your help,
ST

Hi,

It looks like I need to allow user 'root' to access some ressources but I got no idea about how to find out wich (seems to be pts).

CAP_SYS_ADMIN seems to be denied for /usr/bin/lxc-start How (or where) can I add a rule that allows LXC to use CAP_SYS_ADMIN ?

Thanks a lot

You need to disable CONFIG_GRKERNSEC_CHROOT_CAPS, as lxc is needing special privileges while in a container.

-Brad

Hello spender,

Thanks a lot, it's working great right now !
I try to understand what CHROOT_CAPS stands for, I understand that LXC needs thoses privileges, but what are they ? Do you have an idea ?

Thanks

You'd have to trace the binary to know for sure -- CAP_SYS_ADMIN covers a wide variety of things. In this case it was probably the mount/unmount and creation of a namespace.

-Brad

Hi all,

Because it may be usefful for someone that has the same problem as me, I post here the few options that needed (for my 2.6.32.52 kernel) to make it work:

Code: Select all

CONFIG_GRKERNSEC_NO_RBAC=y
# CONFIG_PAX_KERNEXEC is not set
# CONFIG_GRKERNSEC_CHROOT_CAPS is not set
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# CONFIG_GRKERNSEC_CHROOT_MOUNT is not set


CONFIG_GRKERNSEC_NO_RBAC=y

Keeping RBAC compiled-in but not enabled in runtime works as well.

# CONFIG_PAX_KERNEXEC is not set

Not even relevant to LXC and leaves the kernel nearly defenceless.

# CONFIG_GRKERNSEC_CHROOT_CAPS is not set
# CONFIG_GRKERNSEC_CHROOT_MOUNT is not set

Tweakable in runtime with sysctl as well. Also, this should be totally unacceptable for anyone who want to keep superuser contained securely (read: prevent system-wide privilege escalations) inside an LXC. There are ways to setup and run LXC securely (read-only /proc is the most constraining requirement ATM), but the authors of LXC tools just don't bother. I'd suggest to implement a custom launcher using a tree of more-to-less privileged processes.

A solution that works on an Alpine Linux host to install non Alpine containers is to use:

Code: Select all

lxc-create -n xxx -t download

& use an unprivileged image. This does not require

Code: Select all

CAP_SYS_ADMIN

in the chroot during container creation (which the privileged Ubuntu template does for some reason). I've used this for a Debian container also.

Alternatively for a privileged Debian image do this.