[Suggestion] Guidance on Container breakout vulnerabilities

[raesene]

Description: As there have beena set of container breakout vulnerbiities in 2022, in a variety of parts of the stack, it's attracting more attention to this part of cloud native security. It could be good if the CNCF can provide some awareness about the risks of container breakout and possible mitigations that users of containerization technology can use to reduce the risks of this happening.

The topics for guidance might include :-

• Use of hardening techniques on containers (seccomp, Apparmor, SELinux)
• risks of user namespaces (some of the Linux CVEs could only be triggered from unprivileges users if user namespaces are available, which they are by default on popular distributions)
• Hardening by restricting access to features (the CRI-O bug relied on access to setting custom sysctls, which could be blocked by admission control)
• Importance of trusted images (the Containerd bug relies on the use of a crafted container image)
• Use of sandbox/virtualization to reduce risk (gVisor, Firecracker, Katacontainers) and where that might not be effective (e.g. the Containerd issue)

Impact: Help uses of containerization understand and mitigate the risks of container breakout

Scope: Not sure in detail but in principal perphaps a short white-paper/blog post on mitigations and risks, and then something for on-going awareness.

Additional info: These blogs discuss the vulns and have links to the original disclosure and some ideas for mitigation

• ContainerD Breakout
• CRI-O Breakout
• Linux Kernel - cgroups
• Linux Kernel - "Dirty Pipe" and more details and full PoC from Datadog
• Linux Kernel - legacy_parse_param

STAG REP : @ashutosh-narkar

[lumjjb]

Tagging other folks that may be interested to chime in! @lizrice @sublimino @mhausenblas @antitree @raravena80

[lumjjb]

Another thought that was brought up during the discussion was bug bounties as an incentive for these container escapes which may or may not be kernel bugs.

[sublimino]

This is a great idea, and touches on the difficulty of workload-specific container controls that is worthy of deeper discussion.

[lumjjb]

Let's develop a scope and then I think this is a good item to work on while it's topical, has attention of folks.

I think a series of blog posts may be good as well! Maybe having a 2/3 part series:

• What are container breakouts, why should I care?
• What can i do to mitigate / protect against them
• (Stretch goal?) What are some future directions to make breakouts less impactful

Tagging @ashutosh-narkar here who's started looking into a blog process for the TAG. Shall we use this as a pilot?

[lumjjb]

@ashutosh-narkar can you follow-up on getting this in progress

[raesene]

Another possibly useful resource on this one is this list of container breakout vulns

[raesene]

I've started a Hackmd note that I thought could be a good venue to gather ideas on this one.

I think @lumjjb 's idea of a blog series would work well here.

[lumjjb]

I think a long blog would be appropriate. Ash is currently working on how we can get these blogs up and the best way to publish them.

My thoughts is that there can be a long blog, attribution can be direct to authors, or if the authors don't want to have direct attribution (for approvals reasons) we can proxy the tag authorship. I guess we could call it something else as well like technical doc and have an accompanying announcement post

On Thu, May 19, 2022, 9:12 AM Rory McCune @.***> wrote:

I've started a Hackmd note https://hackmd.io/viQwq28URseBDb7b0YC6Rw that I thought could be a good venue to gather ideas on this one.

In terms of content style any thoughts on what would work? I don't think this warrants an entire whitepaper style approach, perhaps a long blog, or whatever we'd call a short whitepaper?

— Reply to this email directly, view it on GitHub https://github.com/cncf/tag-security/issues/881#issuecomment-1131313463, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXLDBTAUJEDIVDS3FHJYHLVKXSWJANCNFSM5SCWW5RA . You are receiving this because you commented.Message ID: @.***>

[stale[bot]]

This issue has been automatically marked as inactive because it has not had recent activity.

[raesene]

I'm still happy to work on this one once we've got a suitable venue/format :)

[ashutosh-narkar]

Hey @raesene I would suggest we do a blog series highlighting the problem and then follow-up with techniques to resolve vulnerabilities with config management, runtime, admission control etc. If you can get stated on a draft and share it via Google docs for ex that would be great! In terms of where we can publish this, the CNCF blog or the STAG site (which we're looking to create) would be a good home for this. Also timing-wise with KubeCon NA coming up, if we can get a blog out before KubeCon that would be awesome! Let us know what you think. Thanks for taking the initiative!

[raesene]

Hi @ashutosh-narkar sure. For the CNCF blog, do you know if they have any writing style guides that we should be following when drafting things up?

[lumjjb]

AFAIK it's only style guidelines around logo and certain cloud native terminology and code of conduct guidelines

Otherwise I believe it's pretty flexible.

On Fri, Aug 12, 2022, 8:51 AM Rory McCune @.***> wrote:

Hi @ashutosh-narkar https://github.com/ashutosh-narkar sure. For the CNCF blog, do you know if they have any writing style guides that we should be following when drafting things up?

— Reply to this email directly, view it on GitHub https://github.com/cncf/tag-security/issues/881#issuecomment-1213078281, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXLDBQ3WM2VM2BEFPTPZMTVYZCEVANCNFSM5SCWW5RA . You are receiving this because you were mentioned.Message ID: @.***>

[fidencio]

Hey! I'm from the Kata Containers side and I'd be interested to help on whatever may be needed.

I've been working on Kata Containers + SELinux support (which touched CRI-O and containerd) and I'm very much interested in the outcome of these articles.

[ashutosh-narkar]

Hello @raesene do you have any update on this? Please let us know if you need any help. Thanks!

[raesene]

hi, no update at this precise moment in time, I've hit a busy patch so have less availability for this, I do plan to return to it though.

[ashutosh-narkar]

Sounds good. Thanks @raesene.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had recent activity.

[mnm678]

Closing due to inactivity. Please re-open if there is renewed interest.