1

I have Amazon Linux 2023 running in a Docker container and I would like to be able to load some custom audit rules into the kernel and ensure they are persisted when the container restarts. I have added the rules to /etc/audit/rules.d/audit.rules and can see them when I cat that file and I'm trying to use augenrules --load to load the rules. However, when I run this command the output I get is

/usr/sbin/augenrules: No change
You must be root to run this program.

I receive this same response even when running the command with sudo (sudo augenrules --load). I am already logged in as root (whoami returns root).

I wondered whether it could be be because auditd service is not started (in which case the output from augenrules is misleading) but I am unable to check that status of this service as service auditd status (and any other service command like service auditd start) command gives me

Redirecting to /bin/systemctl status auditd.service
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

ps -p1 indicates the PID 1 is bash

 PID TTY          TIME CMD
    1 pts/0    00:00:00 bash

I assume this is because I'm running in a container but don't know if this is why augenrules refuses to run when I am the root user even when using using sudo.

What is causing this behaviour?

Improve this question

1 Answer 1

Reset to default
1

Feeding audit rules to the kernel is the host operating system's job, not the container's. There is no kernel in the container: only the host system has one. Your container does not appear to have any kind of init system either, although other containers could be set up with one.

It is a bit misleading to say "I have Amazon Linux 2023 running in a Docker container", because a container is never a complete operating system. It would be more accurate to say that you have a container built out of user-space parts of Amazon Linux 2023, containing only just enough parts to fulfill the purpose for which the container was designed, whatever that purpose is.

Within the container, you may have UID 0 (= the classical definition of being root), but the container's UID numbers are mapped to a per-container range of higher values so that they won't overlap with the UIDs assigned within the host system or in other containers. When you're trying to use augenrules --load, the kernel sees the mapped UID and since it's not 0, rejects the request.

Improve this answer
4
  • 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? Commented Jun 18, 2024 at 22:25
  • 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. Commented Jun 18, 2024 at 23:17
  • 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? Commented Jun 19, 2024 at 1:35
  • 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/… Commented Jun 19, 2024 at 6:40

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.