Could you share also /srv/lxc/innen/config?
@AreYouLoco thanks a lot for your summary. Would you mind elaborating how this problem occurs and how it can be circumvented? I get the same erroneous output as @ssdnvv encountered and tried to create a new container with and without automount enabled as you proposed. While I see a difference in the mount, it does not change that lxc-create failes for me.
Automount enabled:
# mount | grep sda
/dev/sda on /srv type btrfs (rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/)
Automount disabled:
# mount | grep sda
/dev/sda on /srv type btrfs (rw,noatime,ssd,space_cache=v2,subvolid=256,subvol=/@)
Any input is much appreciated, thanks in advance.
Sry for late answer - there is no folder /srv/lxc/innen…
edit: I do have USB3-SSD attached. Comparing mount options with @lorenz it seems my SSD is not detected as such.
@lorenz / @AreYouLoco: Did you install internal or external drive?
there is no folder
/srv/lxc/innen
@ssdnvv did you ever manage to create that unprivileged container?
Did you install internal or external drive?
It’s an internal SSD.
No, I don’t. I will try to install the SSD internally and create again. If this fails I will abandon lxc on Turris routers for good (and resurrect my proxmox /X86 studies).
@ssdnvv @AreYouLoco (can not mention lorenz, only two users)
I tried it today on my Turris. Unfortunately I also get the same errors - I’m using an internal SSD.
IIUC this also won’t fix this problem? lxc: Add metadata for unprivileged containers (!54) · Merge requests · Turris / misc · GitLab
Update: just tried maurer’s repo (posted here a few hours go: Omnia armhf LXC (armv7 32bit) alternative repo discussion - #31 by maurer ) and successfully created an unprivileged debian bookworm container!
lxc-create --name test \
--bdev btrfs \
--template download \
-- \
--dist debian \
--release bookworm \
--arch armv7l \
--server maurerr.github.io/lxc
2 Likes
I can confirm it works using the custom repo - thank alot to
@psiegl for the prework
@AreYouLoco for putting everything together and
@maurer for providing the repo
You rock!
(my mistake)
edit:
The container is up, but not unprivileged:
root@turris:~# lxc-ls -f
NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED
innen RUNNING 0 - 192.168.1.195 [...], [...] false
does that have to do with the mount options of the SSD?
root@turris:~# mount | grep sda
/dev/sda on /srv type btrfs (rw,noatime,ssd,space_cache,subvolid=256,subvol=/@)
I used a “fresh” Omnia: installed 6.4.4, checked the lxc-packes in reforis and then directly follow your instructions.
You need to install additional packages to make container unprivileged. From here Unprivileged LXC container on Turris OS 5.0.0 and set subuid and subgid. Your mount options are fine.
1 Like
This is weird, I went through all the commands but somehow they were not executed. Anyhow, my mistake, after issuing them again, it finally worked:
root@turris:~# lxc-ls -f
NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED
innen STOPPED 0 - - - true
1 Like
Just be sure to use your containers only in your local network. I exposed them even unprivileged to the internet and I got hacked like 3 times already. I am working on a way to be production ready but that is not going to happen before TOS7.0 or even TOS8.0.
The problem is seccomp that was disabled in the kernel so even without dangerous capabilities of containers a skilled hacker can escape a container for example by loading malcious kernel module.
I also found a way to disable CAP_SYS_ADMIN in a container but for now its pointless because without seccomp you can gain those capabilities yourself.
Anyway… as always stay tuned. And I am happy tha it was useful to someone.
What do you mean by “exposed” - I would run Apache webserver and a mailserver, so only expose a few ports, not the whole system.
And what is going to happen with a future TOS version, that will change this situation?
By “exposed” I mean exactly port forwarding. Port is enough to exploit an application. I did mail server.
I hope this [Kernel] [TOS 6.4.1] Seccomp is not enabled in the kernel (#416) · Issues · Turris / Turris OS / Turris Build · GitLab is going to change back to as it is in upstream OpenWRT.
If you look at /usr/share/lxc/config/common.conf this is config file that is disabling the most harmful capabilities in a container and trying to load /usr/share/lxc/config/common.seccomp to block some syscalls that can be run in a container. But that its never happening. So this container is even less secure than privileged one in OpenWRT.
1 Like