podman security - attack vector through GitHub PR checkout

[abitrolly]

/kind feature

Description

I am trying to find a lightweight method for securely evaluating occasional projects on GitHub (if they compile, test, generally usable, etc). When rootless podman came to Fedora, that was one big joy. However, with time, more and more people are expressed concerns that containers (and podman) are insecure, and my frustration grew up to the point that I am writing this ticket.

Describe the results you received:

The usage of podman in Fedora/Red Hat ecosystem all assumes that you control and trust the source you're executing. Event the official https://github.com/containers/toolbox project goes into this trap. And third party tools like https://github.com/podenv/podenv/ also mention that virtual machines are more secure (podenv/podenv#20).

Describe the results you expected:

A walk through the story of checking inherently insecure pull request that tries to steal user credentials, overwrite config files and do conduct other unexpected misdemeanor, and how podman protects from all these treats. That would greatly help to understand podman and container security model.

The story could start with a simple hello world that has nothing to shard, and then gradually introduce new options that users are using (starting with the most popular) and attack vector that open up with each option. The attack vectors could come with mitigation solutions. And everything illustrated with pictures.

Maybe I am asking for too much. In big Enterprise World (tm) this issue would, of course, bring lotsa lotsa money dedicated to raising the security by educating developers and other folks, but here WYSIWYG.

[vrothberg]

Your statements seem rather vague to me. What are the concrete problems or scenarios where Podman is missing something?

Let's take the following statement as an example:

The usage of podman in Fedora/Red Hat ecosystem all assumes that you control and trust the source you're executing

What are these claims based on? Fedora and Red Hat registries provide signed images that Podman checks and verifies.

And third party tools like https://github.com/podenv/podenv/ also mention that virtual machines are more secure (podenv/podenv#20).

In which context and which attack vector?

Again, I am not sure what you are asking for. If there are precise issues or use cases, we can help.

[abitrolly]

In which context and which attack vector?

It is in the issue subject. Checkout PR and execute it. Ensure you can project dir with the container, but it won't stole any sensitive info, won't overwrite filesystem or modify project files to do those things.

What are these claims based on? Fedora and Red Hat registries provide signed images that Podman checks and verifies.

That's exactly the trusted sources I mentioned. My context are untrusted source that should be run in containers.

[rhatdan]

Podman is way more secure then running processes natively.
VMs are more secure then running Podman
Podman inside of a VM is way more secure then VMs
Podman inside a VM inside of a separate physical machine is way safer then running a VM with Podman on your host.

You have to pick your level of risk.

[abitrolly]

@rhatdan yes, so I need to understand what is the level for podman.

[rhatdan]

Podman shares the host kernel within the container, but uses every security feature of the host to isolate the workload.

SELinux, Seccomp, User Namespace, Readonly /proc and /sys. Dropped linux capabilities, namespaced envioronment to prevent view of network, processes, and other parts of the file system...

[abitrolly]

So many scary words, and still not more secure than VMs. So, what about attack vectors. SELinux potentially creates more problems that solves, but it can not be seen without specific scenarios. Here is the scenario of malicious PR request. What components are relevant here? I guess all these are designed to shut some attack vectors, so what are the vectors and risks for this story?

[vrothberg]

SELinux potentially creates more problems that solves.

Again, please quote sources. So far your claims are not backed by data.

Here is the scenario of malicious PR request.

Can you elaborate what you mean by "malicious PR request"? Do you mean that somebody opens a PR with bad intentions to change the code in a way to create security issues?

[abitrolly]

Again, please quote sources. So far your claims are not backed by data.

@vrothberg here is the whole story about SELinux experience - #4794 with a closing summary "This needs to be fixed in the python3 package, I don't see anything for us to do here.", and another one is that if you need to run a container in HOME, the :z option can lock up your profile from booting, because it kills other labels.

Can you elaborate what you mean by "malicious PR request"?

Already wrote twice. Hoped that RedHat security experts would chime in with their list of attack vectors to guard from, but let's start with just one.

1. PR that posts the contents of ~/.ssh to the 3rd party website

[vrothberg]

Well you claim that "SELinux potentially creates more problems that solves" which really needs more data than a single issue. So far SELinux has proven to be a reliable security mechanism to protect from container escapes. Note that I am not saying it is easy to use but I think it's wrong to claim it creates more problems than it solves, especially in the context of security.

Already wrote twice.

I know, but I need to understand the exact problems. The risk of talking about two different things is high when claims are vague.

PR that posts the contents of ~/.ssh to the 3rd party website

That would be caught during reviews and the PR would be rejected.

[rhatdan]

Since this is not an issue, more of a descussion, I am going to close the issue. You can continue the discussion here or open a discussion on github.com.

I have given many talks about container security including explaining VMs versus Containers.
https://www.youtube.com/watch?v=ZE2nI1SwSVk

[abitrolly]

That would be caught during reviews and the PR would be rejected.

Yes, the podman focus on trusted source scenarios is the primary reason I opened this issue. As written in its description "The usage of podman in Fedora/Red Hat ecosystem all assumes that you control and trust the source you're executing.". and this thread just confirms this.

Basically, the answer I've got so far from this thread - if I want to run untrusted sources with podman I should go watch all generic container vs VM security videos to become an expert in estimating the risks, and what I am asking, is a beginner friendly tutorial that is showing what an attack is, and then incrementally introducing how to safely protect yourself from it without shooting yourself in the foot. The difference between two approaches, that the first approach requires a significant investment of time (months) and brain capacity, and the second can be apprehended by a person with modern social media ADHD syndrome.

[TomaszGasior]

@rhatdan You can convert issue to the GH discussion using button in right sidebar if you can manage this repo.