Timeline for Why does augenrules refuse to run even when sudo is used?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 19, 2024 at 6:40 | comment | added | telcoM |
First, Docker itself would have to run with root privileges on the host. Then, your container would have to be started with options giving it the extra privileges required (--privileged, --pid=host, --cap-add etc.). For augenrules specifically, you would need at least --cap-add=AUDIT_CONTROL. Having access to actual UID 0 may not even be necessary if you get that capability granted to your container and the process running augenrules within it. See: docs.docker.com/engine/reference/run/…
|
|
| Jun 19, 2024 at 4:01 | vote | accept | word4q | ||
| Jun 19, 2024 at 1:35 | comment | added | word4q |
Thanks again @telcoM. This container will ultimately run in an AWS EC2 instance so access to the host OS should not be a problem. I realise this is now diverging from the original question so let me know if I should open a new question but I would appreciate ii if you could elaborate on "it is apparently possible to allow some root capabilities within the container". Does that mean I could make it possible for augenrules to be run from inside the container? If so, how?
|
|
| Jun 18, 2024 at 23:17 | comment | added | telcoM | Your understanding is correct. It is apparently possible to allow some root capabilities within the container, but allowing anything that would enable the processes in a container to affect the system-wide settings of the host OS would be a spectacularly bad idea in a hosting environment that is supposed to run containers from multiple users, isolated from each other. So if you are in an environment where you don't have admin access to the host too, I would fully expect any attempts to modify the host kernel settings to fail. | |
| Jun 18, 2024 at 22:25 | comment | added | word4q |
Thanks @telcoM, I'd like to check my understanding. I've checked that in the container id -u root returns 0. Your answer indicates that because "feeding audit rules to the kernel is the host operating system's job" augenrules --load checks the UID that the root user in the container has been mapped to on the host system and fails because the UID returned is not 0. This would imply that, any command which requires root access to the host kernel will fail when the command is executed from inside a container regardless of whether sudo is used. Have I understood correctly?
|
|
| Jun 18, 2024 at 13:06 | history | answered | telcoM | CC BY-SA 4.0 |