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

Do not panic if not root #80

Open
pfactum opened this issue Oct 13, 2022 · 1 comment
Open

Do not panic if not root #80

pfactum opened this issue Oct 13, 2022 · 1 comment

Comments

@pfactum
Copy link

pfactum commented Oct 13, 2022

Hello.

Given the systemd (or a similar system manager) is available, it should be possible to run iodined with very restricted privileges and on behalf of a non-root user (even a dynamically generated one), granting additional capabilities via AmbientCapabilities=. Hence, unconditional panic in check_superuser() should be avoided. So, instead of calling check_superuser(), at least on Linux, there should be a check against required capability (there's libcap-ng for this). For creating a tun device it'd be CAP_NET_ADMIN, for binding on port 53 it's CAP_NET_BIND_SERVICE, for changing the user it is CAP_SETUID and CAP_SETGID.

Thanks.
pfactum added a commit to pfactum/iodine that referenced this issue Oct 17, 2022
@pfactum
check capabilities, not effective user ID
c25eed6 
Under Linux, a process may not be run under root, yet it may have a permission
to do what a superuser may do given specific capabilities are granted.

This commit makes iodine not depend on EUID being 0 in order to run
properly. Instead, in presence of libcap-ng, the following capabilities
are being checked:

* `CAP_NET_BIND_SERVICES` for server to bind to a port, lower than
  `/proc/sys/net/ipv4/ip_unprivileged_port_start`
* `CAP_NET_ADMIN` to operate on a TUN device
* `CAP_SETUID` and `CAP_SETGID` in case server is configured to change
  the user it runs on behalf of

This change is handy if iodine is being run under a non-root user, provided
`AmbientCapabilities=` and `CapabilityBoundingSet=` of systemd are employed
in the first place.

Fixes: yarrick#80
Signed-off-by: Oleksandr Natalenko <oleksandr@redhat.com>
@pfactum pfactum mentioned this issue Oct 17, 2022
Open
pfactum added a commit to pfactum/iodine that referenced this issue Nov 2, 2022
@pfactum
check capabilities, not effective user ID
ebf4e7e 
Under Linux, a process may not be run under root, yet it may have a permission
to do what a superuser may do given specific capabilities are granted.

This commit makes iodine not depend on EUID being 0 in order to run
properly. Instead, in presence of libcap-ng, the following capabilities
are being checked:

* `CAP_NET_BIND_SERVICES` for server to bind to a port, lower than
  `/proc/sys/net/ipv4/ip_unprivileged_port_start`
* `CAP_NET_ADMIN` to operate on a TUN device
* `CAP_SETUID` and `CAP_SETGID` in case server is configured to change
  the user it runs on behalf of

This change is handy if iodine is being run under a non-root user, provided
`AmbientCapabilities=` and `CapabilityBoundingSet=` of systemd are employed
in the first place.

Fixes: yarrick#80
Signed-off-by: Oleksandr Natalenko <oleksandr@redhat.com>
@osevan
Copy link

osevan commented Dec 17, 2023 •
edited
Loading

Could someone merge this?

We need this functionality too.

I want running iodine inside high security container with apparmor protections

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@pfactum @osevan