Any projects aiming for permissions control at a higher level than containers.conf, more like flatpak permissions?

[castedo]

The ~/.config/containers.conf* files and folders enable users to expand or restrict permissions given to containers, relative to the defaults. But it's very low-level and podman/buildah-implementation oriented compared to what flatpak offers:

https://docs.flatpak.org/en/latest/sandbox-permissions.html
https://docs.flatpak.org/en/latest/sandbox-permissions-reference.html

which is higher-level and more user-functionality oriented. My intuition is that this kind of flatpak-like permissioning is higher-level than what makes sense for podman to support. I think there is a too much coordination that has to happen between the host and what's inside the container image.

Are there any projects that aim to provide flatpak-like permissioning for OCI containers? Is flatpak planning to have some kind of CLI/container oriented functionality?

At the moment flatpak seems optimized for GUI apps and not CLI environments. And I'm guessing this is probably how it should be now and in the long-term.

I've hacked together a cheap approximation of flatpak-like permissioning for containers by using shell scripts and environment variables in https://github.com/castedo/cnest. But it's more of an experimental proof-of-concept. Nonetheless, it's been convenient over the years.

[mheon]

@vrothberg was working on something vaguely similar to what you're requesting - where images could specify Seccomp profiles (and, I believe, capabilities) that they required, and anything in the default policies in containers.conf but not requested by the image would be dropped; this would allow individual images to customize their security settings and become more restrictive than our default policies. I don't think much has happened in that area in the last year, though.

Our efforts remain focused, overall, around kernel primitives (seccomp, SELinux, capabilities); we don't really have any concept of portals, or restrictions on what can be mounted into the container (largely because all mounts are explicit, a container without any volumes mounted in has almost no access to the host). We could consider something along those lines, but until now we haven't seen much of a need.

[rhatdan]

I know of none. @vrothberg Any idea?

[vrothberg]

As @mheon mentions above, we have something similar for seccomp profiles (see podman-create docs). Running with --seccomp-policy=image, Podman will look up a label in the image's config that would ship a seccomp profile. There's an ongoing project with another team at Red Hat to come up with an =auto policy that would apply the image's seccomp profile iff it's more secure (i.e., stricter) than the default profile of Podman.

We want to do something similar for capabilities as well. Both ideas were featured in @rhatdan's talk at DevConf CZ '20.

For Flatpak-related questions, I recommend reaching out directly to the Flatpak community.

[castedo]

Thank you all for the video link and comments. This really helps me fully appreciate the depth of how many levels of complexity there are for enabling and disabling so many different inter-dependencies between containers and the host. I am realizing there isn't a single clear simplification of permissions that makes sense for all users of containers. Different users are going to understand vastly different levels of detail. This in turn will lead users to prefer different levels of options. Some will just want to share everything and not think about, like with toolbox. Other will want to fine-tune their local containers.conf down to the level of specific kernel capabilities. Flatpak has chosen a particular level of abstraction for permissions that works well for GUI apps. That probably does not generalize to interactive command line environments. Or at least it's not clear to me that it does. I haven't even been able to decide for myself whether my host and "nest" containers should share PID namespace or not or even if I care! :-)

…

On 1/25/22 03:39, Valentin Rothberg wrote: As @mheon <https://github.com/mheon> mentions above, we have something similar for seccomp profiles (see podman-create docs <https://github.com/containers/podman/blob/main/docs/source/markdown/podman-create.1.md#--seccomp-policypolicy>). Running with |--seccomp-policy=image|, Podman will look up a label in the image's config that would ship a seccomp profile. There's an ongoing project with another team at Red Hat to come up with an |=auto| policy that would apply the image's seccomp profile iff it's more secure (i.e., stricter) than the default profile of Podman. We want to do something similar for capabilities as well. Both ideas were featured in @rhatdan <https://github.com/rhatdan>'s talk at DevConf CZ '20 <https://www.youtube.com/watch?v=_w6H5yAbGj8&t=1099s>. For Flatpak-related questions, I recommend reaching out directly to the Flatpak community. — Reply to this email directly, view it on GitHub <#12935 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKZ4PWBI54S7QDPNE2KQHLUXZOVLANCNFSM5MLGBMMQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>