Bad practices related to security in jitsi images

For example, in Kubernetes it would be normal to run containers with such directives:

securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      readOnlyRootFilesystem: true

Various DevSecOps tools check these directives, for example https://docs.kics.io/queries/kubernetes-queries

But jitsi images prevent such important settings from being applied

Perhaps this needs revision? Otherwise, security is seriously affected

How can we avoid using https://github.com/just-containers/s6-overlay? It seems we need to keep something like this in our mind https://github.com/GoogleContainerTools/distroless and try to move in this direction

[ghost]

Summarize what? Read the first comment carefully.

No container runs with extended capabilities

NET_RAW capability and readOnlyRootFilesystem false = already extended capabilities

And there is nothing we can do thanks to the images. That’s the problem.

[saghul]

@saghul I think once we move s6-overlay to use user other than the root then most of the things would be fixed. As of now we can’t start the container without root user as S6-overlay uses it for managing configuration. We can try version 2.X.X as they have introduced User directive(run S6-overlay without root user) in this version.

Indeed experimenting with 2.X.X should be the way to go here.

@Ais8Ooz8 we get it that this question is more about the best practices for running containers. But there are services like jibri where we require root access for /dev/shm hence it wouldn’t be easy to make them work with non-root user. It would be great if you can create a PR and help the community.

IIRC there is a command line flag to prevent Chromium from using /dev/shm, but we can see how to cross that river when we get there.