Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

process capabilities for run / exec are inconsistent when --userns=keep-id is set #9919

Closed
klobukowski opened this issue Apr 1, 2021 · 3 comments · Fixed by #9942
Closed

process capabilities for run / exec are inconsistent when --userns=keep-id is set #9919

klobukowski opened this issue Apr 1, 2021 · 3 comments · Fixed by #9942
Assignees
@giuseppe @mheon
Labels
In Progress This issue is actively being worked by the assignee, please do not work on this at this time. kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@klobukowski
Copy link

klobukowski commented Apr 1, 2021 •
edited
Loading

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

When running a container in rootless mode with --userns=keep-id the capabilities are dropped as expected:

[test@hostname ~]$ id
uid=1003(test) gid=1003(test) groups=1003(test)

[test@hostname ~]$ podman run --userns=keep-id -it  docker.io/library/archlinux:latest /bin/captest
User  credentials uid:1003 euid:1003 suid:1003
Group credentials gid:1003 egid:1003 sgid:1003
Current capabilities: none
securebits flags: none
Attempting direct access to shadow...FAILED (Permission denied)
Attempting to access shadow by child process...FAILED
Child User  credentials uid:1003 euid:1003 suid:1003
Child Group credentials gid:1003 egid:1003 sgid:1003
Child capabilities: none
Child securebits flags: none

However, If I run a container in the background:

[test@hostname ~]$ podman run --userns=keep-id -it  docker.io/library/archlinux:latest /bin/sleep 1000

and exec another command in the same container, the UID seems to be mapped correctly but the capabilities are not dropped by default:

[test@hostname ~]$ podman exec -itl /bin/captest
User  credentials uid:1003 euid:1003 suid:1003
Group credentials gid:1003 egid:1003 sgid:1003
Effective:    00000000, 800405FB
Permitted:    00000000, 800405FB
Inheritable:  00000000, 800405FB
Bounding Set: 00000000, 800405FB
Ambient :     00000000, 800405FB
securebits flags: none
Attempting direct access to shadow...FAILED (Permission denied)
Attempting to access shadow by child process...SUCCESS
Attempting to regain root...SUCCESS - PRIVILEGE ESCALATION POSSIBLE
Child User  credentials uid:0 euid:0 suid:0
Child Group credentials gid:0 egid:0 sgid:0
Child capabilities:
Effective:    00000000, 800405FB
Permitted:    00000000, 800405FB
Inheritable:  00000000, 800405FB
Bounding Set: 00000000, 800405FB
Ambient :     00000000, 800405FB
Child securebits flags: none
Attempting direct access to shadow...SUCCESS

To fix this I need to specify the --user option explicitly even though the UID is already mapped via --userns=keep-id

[test@hostname ~]$ podman exec --user 1003:1003  -itl /bin/captest
User  credentials uid:1003 euid:1003 suid:1003
Group credentials gid:1003 egid:1003 sgid:1003
Current capabilities: none
securebits flags: none
Attempting direct access to shadow...FAILED (Permission denied)
Attempting to access shadow by child process...FAILED
Child User  credentials uid:1003 euid:1003 suid:1003
Child Group credentials gid:1003 egid:1003 sgid:1003
Child capabilities: none
Child securebits flags: none
[

Steps to reproduce the issue:

as above

Describe the results you received:

Process capabilities are different for podman run and podman exec commands.

Describe the results you expected:

podman exec should drop the capabilities for the user process by default if --userns=keep-id was set.

Output of podman version:

Version:      3.1.0
API Version:  3.1.0
Go Version:   go1.16.2
Git Commit:   9f09fb62cba8f44c18eda84db3e72aab3ae76046-dirty
Built:        Wed Mar 31 16:46:48 2021
OS/Arch:      linux/amd64
@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Apr 1, 2021
@rhatdan
Copy link
Member

rhatdan commented Apr 5, 2021

@mheon @giuseppe This is pretty serious. Is there any way to know when we are execing into the container, that we are running with a keep-id user namespace?

@mheon
Copy link
Member

mheon commented Apr 5, 2021

We don't retain keep-id itself. I suppose we could parse the userns mappings to determine what's going on there?

@mheon
Copy link
Member

mheon commented Apr 5, 2021

Found it.

@mheon mheon added the In Progress This issue is actively being worked by the assignee, please do not work on this at this time. label Apr 5, 2021
@mheon mheon mentioned this issue Apr 5, 2021
Merged
mheon added a commit to mheon/libpod that referenced this issue Apr 6, 2021
@mheon
Ensure that --userns=keep-id sets user in config
541252a 
One of the side-effects of the `--userns=keep-id` command is
switching the default user of the container to the UID of the
user running Podman (though this can still be overridden by the
`--user` flag). However, it did this by setting the UID and GID
in the OCI spec, and not by informing Libpod of its intention to
switch users via the `WithUser()` option. Because of this, a lot
of the code that should have triggered when the container ran
with a non-root user was not triggering. In the case of the issue
that this fixed, the code to remove capabilities from non-root
users was not triggering. Adjust the keep-id code to properly
inform Libpod of our intention to use a non-root user to fix
this.

Also, fix an annoying race around short-running exec sessions
where Podman would always print a warning that the exec session
had already stopped.

Fixes containers#9919

Signed-off-by: Matthew Heon <[email protected]>
mheon added a commit to mheon/libpod that referenced this issue Apr 16, 2021
@mheon
Ensure that --userns=keep-id sets user in config
0cbd322 
One of the side-effects of the `--userns=keep-id` command is
switching the default user of the container to the UID of the
user running Podman (though this can still be overridden by the
`--user` flag). However, it did this by setting the UID and GID
in the OCI spec, and not by informing Libpod of its intention to
switch users via the `WithUser()` option. Because of this, a lot
of the code that should have triggered when the container ran
with a non-root user was not triggering. In the case of the issue
that this fixed, the code to remove capabilities from non-root
users was not triggering. Adjust the keep-id code to properly
inform Libpod of our intention to use a non-root user to fix
this.

Also, fix an annoying race around short-running exec sessions
where Podman would always print a warning that the exec session
had already stopped.

Fixes containers#9919

Signed-off-by: Matthew Heon <[email protected]>
jmguzik pushed a commit to jmguzik/podman that referenced this issue Apr 26, 2021
@mheon @jmguzik
Ensure that --userns=keep-id sets user in config
234bf4c 
One of the side-effects of the `--userns=keep-id` command is
switching the default user of the container to the UID of the
user running Podman (though this can still be overridden by the
`--user` flag). However, it did this by setting the UID and GID
in the OCI spec, and not by informing Libpod of its intention to
switch users via the `WithUser()` option. Because of this, a lot
of the code that should have triggered when the container ran
with a non-root user was not triggering. In the case of the issue
that this fixed, the code to remove capabilities from non-root
users was not triggering. Adjust the keep-id code to properly
inform Libpod of our intention to use a non-root user to fix
this.

Also, fix an annoying race around short-running exec sessions
where Podman would always print a warning that the exec session
had already stopped.

Fixes containers#9919

Signed-off-by: Matthew Heon <[email protected]>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 22, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@giuseppe giuseppe

@mheon mheon

Labels
In Progress This issue is actively being worked by the assignee, please do not work on this at this time. kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Ensure that --userns=keep-id sets user in config mheon/libpod
5 participants
@giuseppe @rhatdan @klobukowski @mheon @openshift-ci-robot