search

inmanta / inmanta

Repository for the inmanta package
Apache License 2.0
0 stars 0 forks source link

Don't give sudo access to inmanta user in containers #92

Open edvgui opened 2 years ago

edvgui commented 2 years ago

Getting rid of those two lines should do it I think https://github.com/inmanta/inmanta/blob/d9fc1275038a466885920298661e746b01f40108/docker/Dockerfile#L30-L31

sanderr commented 2 years ago

@edvgui could you add some motivation for this? Is this for security purposes, to prevent escalation outside of the container?

edvgui commented 2 years ago

A little bit of context: The isolation that docker provides with regard to the user namespace is a bit weak, in the sense that the user id of a process running in a container is the same on the host (there is no mapping like it is possible with podman where you could say, user root in the container matches user 1000 on the host). This means that a root process in the container, is also running as root on the host.

I think this was a request from one of our customers. In their infra, they can not have root access to remote machines, but they can install containers on those. So it was an issue that simply installing the inmanta orchestrator container could allow them (using the sudo command in the container on the inmanta user) to start root processes on the host (using the exec resource on the internal agent for example).

@bartv can you confirm that this is correct? (That this is indeed the issue we are trying to solve here)

sanderr commented 2 years ago

That's interesting. What would stop them installing another container through which they can escalate?

sanderr commented 2 years ago

Other than that, should we pick this up soonish? I'm moving a bunch of tickets to the backlog, not sure if I can move this one as well.

edvgui commented 2 years ago

That's interesting. What would stop them installing another container through which they can escalate?

I don't know enough about their infra to answer that question unfortunately, maybe they only have access to a list of containers that have been white listed by their security team, and changing this is a requirement for our container to go into that list?

That's interesting. What would stop them installing another container through which they can escalate?

Another question for @bartv, this change doesn't impact me personally, so I guess it depends on how much our customers need this container.

bartv commented 2 years ago

A container needs to be as minimal as possible. If sudo is not required, then why enable it? Security is also defense in depth

bartv commented 2 years ago

@arnaudsjs @edvgui Is this still relevant with the changes we made?

arnaudsjs commented 2 years ago

I think so. sudo is available but I don't see a reason why we need it.