Replies: 12 comments 8 replies
-
|
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:
What are these claims based on? Fedora and Red Hat registries provide signed images that Podman checks and verifies.
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. |
Beta Was this translation helpful? Give feedback.
-
I know that Red Hat signs its container images, but I was not aware that Fedora did so. |
Beta Was this translation helpful? Give feedback.
-
|
Actually I don't believe Fedora does, just Red Hat. |
Beta Was this translation helpful? Give feedback.
-
|
Which is something that really ought to change. I filed a ticket with Fedora releng for it. |
Beta Was this translation helpful? Give feedback.
-
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.
That's exactly the trusted sources I mentioned. My context are untrusted source that should be run in containers. |
Beta Was this translation helpful? Give feedback.
-
|
Podman is way more secure then running processes natively. You have to pick your level of risk. |
Beta Was this translation helpful? Give feedback.
-
|
@rhatdan yes, so I need to understand what is the level for |
Beta Was this translation helpful? Give feedback.
-
|
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... |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
Again, please quote sources. So far your claims are not backed by data.
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? |
Beta Was this translation helpful? Give feedback.
-
@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.
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.
|
Beta Was this translation helpful? Give feedback.
-
|
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.
I know, but I need to understand the exact problems. The risk of talking about two different things is high when claims are vague.
That would be caught during reviews and the PR would be rejected. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Yes, the Basically, the answer I've got so far from this thread - if I want to run untrusted sources with |
Beta Was this translation helpful? Give feedback.
-
|
The answer to your question is tricky and involves a long discussion, which is why I sent you a 1 hour video. For running normal semi trusted applications, then Podman is plenty of security. |
Beta Was this translation helpful? Give feedback.
-
|
We've already got a long discussion, but so far not an even an entrypoint to the answer. So, what is the most obvious line of defense that a hackme.com container would target first when trying to steal SSH keys? I suppose it will (1) try to find the location of the file, and for that it will need to (1.a) know the username. or just try to read (1.b) |
Beta Was this translation helpful? Give feedback.
-
|
And in which cases it might succeed? |
Beta Was this translation helpful? Give feedback.
-
|
It would not have access to the HOST OS, only the files within its container image. So getting access to /root/.ssh or $HOME/.ssh is blocked by several security mechanisms including SELinux. Basically they would need to figure a way to take over the host kernel. Or figure a way to get access to the host OS file system and then disable SELinux. |
Beta Was this translation helpful? Give feedback.
-
|
@rhatdan You can convert issue to the GH discussion using button in right sidebar if you can manage this repo. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks I did not know that I could do this. |
Beta Was this translation helpful? Give feedback.
-
/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
podmancame to Fedora, that was one big joy. However, with time, more and more people are expressed concerns that containers (andpodman) are insecure, and my frustration grew up to the point that I am writing this ticket.Describe the results you received:
The usage of
podmanin 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
podmanprotects from all these treats. That would greatly help to understandpodmanand 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.
Beta Was this translation helpful? Give feedback.
All reactions