So do I! It seems fairly risky to have a ‘within-container-root’ map to root on the router itself…
Exactly those kinds of questions / knowledge areas are the reasons why I am asking for documentation (or an official community wiki so the community can start documenting such stuff).
P.S. I looked into the “procedure” but it is not a fairly simple one. 
How “dangerous” would it actually be to run containers as root (is it only a theoretical issue; or are (future)threats actually significant)?
Having root inside a container and having root outside of it are different things. There may be future threads but these will be relevant not only to lxc but even to docker and others. The downside with unprivileged containers is that a root account inside the container may get root on the host if there is any useful bug out there. Privileged (root) container would also have this problem and may have it even before unprivileged containers get the hole but i worry far more about anyone starting a container that may give him a real root than about root starting one.
Yes i may be the only person on the device but this still makes me worry. A php shell may be enough to get root…
Enough with future threads and a bit of paranoia… Containers are still chroot on steroids nothing more and nothing less…
Edit: with anyone i mean really anyone including that idiot that got a hacked php-shell or something like that on my device.
Yah, that was my _un_expressed underlying point: I’d rather have LXC (or docker) containers run unprivileged!
But that is hard to setup / maintain and even then there is still a fundamental thread of a root-break-out if the uid-mapping functionality is circumvented in one way or another). But running containers privileged (as root) is ofc. even more risky.
An actual root-break-out of the container would mean root access to my router * shivers * . The exact opposite of why I love the Omnia)! 
So, in your opinnion @adminX (and others of course!);
Should I only consider using LXC on the Omnia un-privilidged (if at all)? I practically “bought” the router for its “virtual server” functionality…
IMHO if you control the container the risk is low. I wouldn’t give shell access to the container to everybody on the Internet, but it you are admin of the thing inside the container somebody would have to break into your container first (which shouldn’t be easy if you manage it correctly), then he would steal your mails and find out he is inside container and only after that he can try to escape. But I would say that that would need targeted and persistent and lucky attacker who finds security issues in system in your container, exploit them and at the same time security hole in LXC on Omnia and exploit it in the window before those holes will be fixed by updates.
Hmmm… if you put it like that…
@miska So you argue that even running priviliged containers - without UID-mappings (being fairly difficult to implement on the Omnia) - should be pretty safe, as long as I am not storing any top-secret governmental plans on my network (not making me a high-value target for dedicated hackers), and only giving myself a CL-login?
@nerdpunk that stuff you posted is a bit to far fetched for me at this moment (don’t have enough time to really understand it all). But if you (or anyone else ofc.) find any simpler how-to’s than please post them here?
sorry, it is as it is 
at the moment you need to build your own stuff, which implies some knowledge about openwrt/lede build system and so on… i really can’t write a howto for beginners (lack of time)
for the moment you should be fine, also with “normal” containers… if you’re really paranoid, revoke as much capabilities as you can (although default templates should be perfect in that manner, already), read about securing your services and so on…
you still can make your containers unpriviledged, later…
maybe miska knows if unpriviledged containers will be supported in the next Turris-OS release?
@woosting Yes. If you maintain everything up-to-date (easy with Omnia), it should be very/extremely hard to break into your network through the container, I would say that much more probable is that somebody will crack your WiFi password.
@nerdpunk No idea. Probably at the scope you described it will be supported at some point in the future, no idea which version, wouldn’t bet on the next one.
To get a root break-out you would have to get root in the container and then break out of it. If it is a privileged or an unprivileged one will not differ in the end result. If you can get root somehow in the container than the same probably works on the host.
Containers are a really cute way to have incompatible versions of the same software on the same host. They also make things like php-shells less useful if you only have the minimum required software in the container. But in the end i would not trust them as a hard security boundary.
I would use multiple containers. One for e-mail. One for web. Maybe even one for webmail. This way the containers only need eg postfix+dovecot and nothing more. Less software available means less software able to have bugs. A 200MB+ ubuntu install may not be the best starter but a small busybox only or alpine linux image may work quite well.
The risk of getting hacked should not put your plan aside. The risk is always there. If you take the normal care you should always take containers give you a bit of security and the hackers a harder time.
side note: even hypervisor have their problems and are not bulletproof.
So the “docker-way” (ideally one coherent appliance per container), why?
nods agreeingly
However; at the same time multiple “OS-es” to maintain at the same time, or is that neglect-able?
You would have to maintain the base no matter if it is one or many containers and if it is docker-style base-image + overlay or plain container with independent installations.
If you use debian or unbuntu apt-get update && apt-get upgrade take a few seconds to type. If something goes wrong chances are only some containers go down.
for i in web mail samba ; do lxc-execute -n $i apt-get update && lxc-execute -n $i apt-get upgrade ; done
Something like this will update all at once and is in a script file no more time-consuming than one container done manually.
As @adminX said, updating most distributions (not only ubunutu) is quite fast (I guess only exception would be Gentoo). But yes, multiple containers is more work and contrary to Omnia, those distributions wouldn’t update themselves automatically by default. But that can be scripted. And if you want to go the way with multiple containers, I would suggest to use some orchestration tool like Salt Stack.
As for my opinion, I would put everything in one container. It’s more convenient and I believe I can secure it well enough. But as with most things, this is about how paranoid you are versus how lazy you are. I’m more lazy than paranoid and security is good nowadays and any maintained distro publishes security fixes fast and most of the security issues nowadays is crashing application, not giving attacker an access.
agreed, i’m using two atm, one for web- and one for communication-related stuff
In anticipation of my Omnia twiddle I am experimenting with LXC a lot. I am running into various issues though (esp. on ARM based devices). Ok… The Turris Omnia will contain an ARMv7 CPU (making things less painful), I’m still a bit worried. Luckily the LXC of theOmnia gets official support from CZ.nic and promised to work out of the box with Debian (which one of the main points for me to support this project). However I currently have two questions/worries:
LXC_SECCOMP, CONFIG_SECCOMP_FILTER and CONFIG_HAVE_ARCH_SECCOMP_FILTER modules to set in its configuration?I am asking as:
ad1: Testing it on my (albeit ARMv6 Rpi1B) led to seccomp issues. 
ad2: I have read about (and encountered) the systemd problem running Debian8 in a non-systemd “mother OS” in my preperations.
This all got me a bit worried as I was unable to solve them for my Rpi1B, and am worried the Omnia will give me similar issues (albeit ARMv7 receiving much better support by Debian)…
Would you be so kind to shine your lights on my worries (either here or on the respective StackExchange pages) @miska @adminX @bernstein (and of course anyone else). I’m asking you guys as you knowledgeably helped me over some hurdles before!
CONFIG_HAVE_ARCH_SECCOMP_FILTER gets set if there is some code that is arch-specific. It doesn’t matter if this is y or n.
LXC_SECCOMP (seccomp supporting LXC) 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.
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.
Thanks for your - as always - elaborate answer @adminX!
Taking the Seccomp topic discourse to its own/separate thread (as it is worthy of it IMHO).
Leaving this thread open for more general ‘virtual server’ banter! 
I would not count on privileged container escape exploits to be patched quickly. From the LXC devs:
“As privileged containers are considered unsafe, we typically will not consider new container escape exploits to be security issues worthy of a CVE and quick fix.”
I am running Turris OS in a LXC container. I would like to use to test some configurations.
I can access it using lxc-attach.
However the network is not setup and I cannot access the web interface.
How can I put the LXC in the network?
@Leonardo since you can lxc-attach you can log-into your Omnia box via SSH. Run lxc-info <containername> while the container is running it should give you an IP (if it has one - not sure if it by default has a dhcp-client running). I’m assuming you can simply connect to that IP (Turris’ web-UI listens on default http port 80 I think). Alternatively - if you indeed use DHCP (as do 80% of router users) - you could also have a look at the dhcp-lease table in LuCi (the perspective of the Omnia on the IP-addresses handed out).
I think the guys from cz-nic have configured LXC as such that containers are normally automatically bridged (dealt with as if they are actual computers plugged-into the nework separately; i.e.get their own IP etc if you are using DHCP) to your network.
I haven’t run ‘Turris OS’ yet (virtually), but I assume it is the case when that template too to build an LXC container. But - as normally - a device has to be hooked onto the Omnia to run the initializing configuration setup, I am unsure…
P.S. I am not sure what the effect is of running router software behind a router (will it - by default - start dishing out IP’s too for instance? Make sure you are not creating a conflicting situation of any sort!
Keep us updated, and let us know how you solved it!