Omnia container security (LXC_SECCOMP )

Continuing the discussion from Multiple virtual servers (LXC containers) possible?:

Seccomp is used for container security (mostly sand boxing them - by limiting system calls). But on (older) ARM systems and/or average routing OS software it it is not (out of the box) offered / set in kernels.

How will it work on the Turris Omnia (seeing cz.nic promised LXC containerization out of the box)?

Will the kernel of the Turris Omnia be compiled having: LXC_SECCOMP, CONFIG_SECCOMP_FILTER and CONFIG_HAVE_ARCH_SECCOMP_FILTER modules to set in its configuration?

Good to know! So from a practical point of view there is no need to give that much thought than. Could you nevertheless elaborate on that (understanding helps me reach peace of mind :innocent:); i.e. where should the code that is arch-specific be present in order for the module to get set in the kernel?

[quote=“adminX, post:56, topic:443”]LXC_SECCOMP gets selected by default if KERNEL_SECCOMP is set.

KERNEL_SECCOMP seems to not be set by default. This makes sense for OpenWRT in general but hinders secure usage of LXC.OpenWRT will never enable it by default as it costs some cpu time.[/quote]

  • Is it safe to assume that the official (Omnia) development involves altering the openWRT software/kernel as such that all necessary kernel modules are active for LXC to safely (on the level that can be expected from containers in general) work out of the box?

[quote=“adminX, post:56, topic:443”]I’m trying to recompile OpenWRT with SECCOMP enabled for the ARMv6-RPI. This is based on the current (2 weeks old) development code for the Omnia and the 4.4 kernel from LEDE and some shortcuts like editing system headers.

There are still some build errors currently but these get ironed out or the packages disabled.
[/quote]

That would be frieak-kin awesome, as than (having installed that OpenWRT on the Rpi1) one could start playing with the software that is gong to run on the Omnia, on the Rpi, right (ofc. many routing stuff will not work… no wifi/ethernet ports etc.), right?

What about the third one: CONFIG_SECCOMP_FILTER; should/will it be set on the Omnia?

I’m sorry if I am over-asking / sound newbish here, but I have little to no kernel knowledge yet (and while googling it all it seems fairly complex / a lot to take in at once), and the LXC containerization is one of the main features why I backed this project (next to the safe/transparant routing and supporting the open-source community orc.).

Any other knowledgeable people care to shine their light on the matter (I’m thinking "the usual suspects here; @miska, @bernstein, @nerdpunk, etc.)?

My most important question is marked with the bullet, an answer to those would be highly appreciated!

Just a little something to add to the least important question:

That would be frieak-kin awesome, as than (having installed that OpenWRT on the Rpi1) one could start playing with the software that is gong to run on the Omnia, on the Rpi, right (ofc. many routing stuff will not work… no wifi/ethernet ports etc.), right?
[/quote]

Actually not entirely as RPi1 is ARMv6 and Omnia is ARMv7 so for Omnia you can get rootfs tarball for most of the distros as it is quite mainstream, while ARMv6 is and always was a zombie :slight_smile: So especially regarding the rootfs that you would run inside, you would need to get something different and compiled differently.

1 Like

Acknowledged! Luckily Debian (my distro of choice) offers the old ARMEL builds for it.

One could regard being limited by the ARM6 instruction set (as on Rpi1 testing) as a good thing (psychology wise): As one does not get spoiled by features that may not be present on the Turrsi Omnia later. In fact, as such, the Turris Omnia (having ARM7) will have more / better / newer options then the old hardwareI am using now to test on (i.e. making life easier than I am getting used to now).

Running it on an RPI1 is like pushing on a bruise, to have less pain later when ‘our precious’ arrives! :stuck_out_tongue:

1 Like

As long as you think of them as chroot with extras yes and if you are paranoid no. Root is root and stays root.
SECCOMP should be possible by recompiling the kernel and a few packages (lxc, procd and ocserv) and losing OABI compatibility. And you will get some not so funny musings with opkg install kmod*.

Take the official OpenWRT (snapshot brcm2708) build. It is far less PITA. The Turris defaults may drive you crazy but to be fair their foris web interface is really nice. I wish every router would be such a breeze to setup while still forcing you to some simple security measures. Custom passwords for foris, luci and wifi are more or less a requirement.

You can not use one of the official prebuilt rootfs for Turris Omnia but lxc-create runs debootstrap and will install raspbian (Debian recompiled for ARMv6 hardfloat) just fine.

systemd is no problem with lxc-create and raspbian jessie for booting the starting the container. These bugs are fixed. But i got some quite interesting fun with lxc-console. It opens /dev/tty1 and /dev/pts/1 at the same time and systemd spawns 2 gettys.

The armel builds and even raspbian are slow. eMMC (and eSD) and SATA are simply faster. Being slow will also restrict you sometimes. You simply don’t do something you would otherwise try.