@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.