Andrew I had a hard time following what you are asking, but I think you just want to run a container with the UID of the user who launched it.

podman run --userns=keep-id ...

Does this for you

/etc/subuid and /etc/subgid, provide a mechanism for users to have more then one UID, and often to emulate root with namespaced capabilities.

Most OCI container images from container registries have more then one UID/GID within them. Often they have root and not root users.  Pulling one of these images is not allowed by default unless the podman user has more then one UID.  We did add a feature to storage.conf called ignore_chown_errors that allows you to pull and install an image all as your UID within your system, and then you can run it
with your uid, using the --userns=keep-id flag.


On 12/15/20 13:00, Scott McCarty wrote:
Andrew,
     Thank you for this extensive proposal. Some thoughts inline...

On Mon, Dec 14, 2020 at 9:26 AM Andrew G. Dunn <agd@epiphyte.org> wrote:
Greetings, thanks for this awesome tool and growing community!

We've been deploying podman, using systemd with podman directly (instances,
and pods), or podman kube. We've been internally talking about a couple topics
related to hardening and have been neglecting to find a place to initaite
discussion, as it's a bit meta in nature. The mailing list looks like the
right place!


Everything proposed here comes down to personal preference, but the reason we
wanted to share our discussion with the community is to explore what the sane
defaults should be for users of podman.

# rootless, rootless as non-root

Brian Smith via this video [0] uses the terminology "rootles-podman-as-non-
root". We understand that (likely niavely) to be "shifting twice":

 - once from root on metal, to user on metal
 - once more from root and user coliding to root in the container being
remapped off user (using subuid/subgid)

For those reading, check out Brian's videos, they are amazing. He allowed me to review them before he published them and they are great. Another follow up piece of content that might interesting you is this blog:

https://www.redhat.com/en/blog/understanding-root-inside-and-outside-container

I "think" what you are getting at is that there are root inside and outside the user. It's best not to use root anywhere if possible - run podman as a user (ex fatherlinux), and run the process in the container as a user (ex sync). When you do this, you limit the damage that the podman user can do, as well as what a hacker can do. You are protecting the host from the user, and the containers from each other. 

 

Discussion here [1] shows that if you were to attempt to user systemd-sysuers
or systemd-tmpfiles to package something (using podman) you'd not be able to
set up the subuid/subgid mappings. Poettering goes on to point out that
subuid/subgid as implemented has flaws [2].

We've been deploying as "rootless-podman-as-non-root" but have recently been
considering removing the subuid/subgid configurations as the podman instances
for us are already running under "system" users (e.g. `/sbin/nologin`). We
can't seem to grasp the specific advantage when doing a "systems" deplyoment,
and there is a distinct disadvantage when having to deal with file permissions
that are uid/gid shifted (pressing one to use more permissive permissions than
what would typically be necessary).

We realize that "rootless-podman-as-non-root" is valuable for things like
toolbox [3], where the example would be a non-root user wanting to run a
container mapped once again off their namespaces (e.g. a browser or something
of high risk).

So, I can't comment too much on this, as I am not familiar with this systemd feature. That said, I know that the identity management team has been looking at centralized solution to manage subuid/subgids across clusters of hosts as well as different software on those hosts. 

 

# systemd unit hardening

systemd itself has a _lot_ of hardening features available [4], one can make a
unit wrapping podman and then examine it via `systemd-analyze security
unit.service`. As podman has a `podman generate systemd` it'd be extremely
interesting to have some discussion on how these features of systemd could be
enumerated/used by default.

This sounds quite interesting, and something I would be interested in as the product manager for Podman in RHEL. These are the kinds of Feature ideas that I'd love to discuss.

 

# seccomp/eBPF/selinux

There is already some documentation on generating seccomp profiles [5], as
well as udica [6]. These seem to be very powerful tools to create instance
specific isolation for deployments. We're very interested in these, but we're
wondering how to practically apply these techniques for something that is a
complex monolithic ontainer (e.g. gitlab).

So far, at least in RHEL, we've provided these tools to users but pretty much left them to be configured for themselves. The main problem with seccomp is, the default rules have to either 1. be so loose as to not be very useful or 2. so tight that people will shut it off. 

Likely both Secomp and udica are best customized on a workload by workload basis, and the user of Podman is likely the SME for that workload more than the Podman team or in my case, RHEL.

 

# Questions

Does the podman community have a line to the systemd community to talk about
leveraging subuid/subgid, is there a more systemd focused formalism for
accomplishing this shift?

For sure.

 

What does the "shifting twice" accomplish for you when deploying a system
style service? (as opposed to the other hardening options mentioned below)

Will the podman community consider systemd to be a "first class" deplyoment,
and split that style of deployments into "systems" and "users" where on
"systems" we can go far deeper into the expected defaults/patterns (toolbox
handling the "users" use case well)?

Would someone working on selinux/udica consider a complex container use case
(e.g. keycloak from RedHat itself, or gitlab as an upstream partner) for the
generation of profiles?

What are the patterns with generating profiles with udica? Would it be most
reasonable to generate these profiles on a test system, generating a profile
each time you instance the container, then deploying those profiles to
production?

Tom, I think this might be a great subject for the next Podman Community meeting? What do others think? It feels sufficiently complex enough to requires some synchronous communication?

 

We're mainly just wanting to hear from folks who are deploying podman as to
how they are using these tools, and what other tooling/techniques may be out
there that we could be looking at. Thanks for considering the inquiry!

[0]: http://www.youtube.com/watch?v=ZgXpWKgQclc&t=7m40s
[1]: https://github.com/systemd/systemd/issues/13717#issuecomment-711167021
[2]: https://github.com/systemd/systemd/issues/13717#issuecomment-539476282
[3]: https://github.com/containers/toolbox
[4]: https://www.freedesktop.org/software/systemd/man/systemd.exec.html
[5]: https://podman.io/blogs/2019/10/15/generate-seccomp-profiles.html
[6]: https://github.com/containers/udica













_______________________________________________
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io


-- 
--
The Delicate Art of Product Management with Open Source: http://crunchtools.com/open-source-in-business-2020/
--

Scott McCarty
Product Management - Containers, Red Hat Enterprise Linux & OpenShift
Email: smccarty@redhat.com
Phone: 312-660-3535
Cell: 330-807-1043
Web: http://crunchtools.com

_______________________________________________
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io