Bad practices related to security in jitsi images

[ghost]

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

[saghul]

Otherwise, security is seriously affected

What specifically?

[ghost]

For example Lack Of Self Isolation: Inside a Container Exploit

[saghul]

Can you summarize? One shouldn't need to watch a 24 minute video to get an accurate bug report. No container runs with extended capabilities so I'm not sure what the attack vector is here.

[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]

You haven't explained what the attack vector is.

Also, how is the net raw cap enabled? Is that a default? We don't enable it explicitly AFAICT.

[prayagsingh]

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

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

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