Remove --disable-seccomp-filter-sandbox when starting chromium

Technical Support
, ,
1

The new torizon/chromium-imx8:4 container start chromium with parameter --disable-seccomp-filter-sandbox (as in the past).
But now Chromium complains that

You are using an unsupported command-line flag: --disable-seccomp-filter-sandbox. Stability and security will suffer.

I’ve already opened an issue and a PR months/weeks ago on github, but I got no feedback.
Can someone from Toradex side take care about them?
Thanks

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello!

To configure Chromium security settings on Toradex hardware using Torizon, it is recommended to use the --security-opt seccomp=unconfined option at the Docker container level. This approach is preferred over directly passing sandbox flags to Chromium. You can find more details in the Toradex documentation on running Chromium in kiosk mode and working with multiple containers.

Here is an example of how to run the Chromium container on an iMX8 device:

docker run -d --rm --name=chromium \
    -v /tmp:/tmp -v /var/run/dbus:/var/run/dbus \
    -v /dev/galcore:/dev/galcore --device-cgroup-rule='c 199:* rmw' \
    --security-opt seccomp=unconfined --shm-size 256mb \
    torizon/chromium:$CT_TAG_CHROMIUM \
    --virtual-keyboard https://www.toradex.com

If you have any further questions about configuring software on Toradex devices, feel free to ask!

Best regards,
Toradex AI Assistant.

3

Greetings @vix,

I spoke with the team about this. We will not be removing this parameter. Without this parameter if Chromium were to make a syscall that was not supported/recognized by the underlying kernel this would result in a hard crash which we would like to avoid. Since we have Chromium in a container, and the underlying kernel can change depending on machine. and OS version, this is preferable for us.

Best Regards,
Jeremias

4

I’m curious.
The parameter disables one of the chromium sandboxes and so it runs un-sandboxed.
I would have said that in this situation a risk for hard crash should be greater.
But the team says the opposite.
Can you give some more detail or links on this topic?

5

@vix hey, so Docker has a default profile for the seccomp filter (Seccomp security profiles for Docker | Docker Docs) which would maybe crash on us due to using ‘unallowed’ syscalls that our Docker version doesn’t know about.

For example, this user had this issue before running a newer container release on an older version of Torizon (older kernel, older Docker runtime) Using openssh-server in container torizon/debian:3-bookworm - #5 by leon.tx.

With the --disable-seccomp-filter-sandbox option (and the --security-opt seccomp=unconfined container option) we’re basically allowing every single syscall to come through the container runtime and the seccomp Chromium sandbox.

I would have said that in this situation a risk for hard crash should be greater.

This is more about security than crashing, but as our Chromium deployments are generally very controlled, it’s completely fine to do it. It’s basically ensuring syscalls from Chromium won’t crash the system due to a unwarranted security concern. It makes sense on Desktop where you may open a myriad of random websites, not so much on embedded. Of course users can and should evaluate everything for their particular deployments.