Add `allow2audit` to images about bottlerocket HOT 7 OPEN

@fheinecke Thanks for opening this issue! Bottlerocket team will discuss on this and get back to you soon.

from bottlerocket.

@vyaghras Sure. So occasionally software needs to be added to the host (typically under /opt). While this isn't terribly common, it's needed to do things like adding a container runtime (#4070). Typically any software that needs to run on the host and execute under namespace 1 will require a lot of privileges. I'd like to be able to use industry-standard tools to determine the minimum set of privileges required, so that I can use the work done in #1016 to load a module that restricts permission to this minimum set.

Another example of where this would be useful is troubleshooting containers that require extended permissions. If I have a workload that needs a custom selinux policy (or a current policy extended), then having allow2audit would make discovering the required permissions and writing the policy significantly easier. Somewhat common cases for this are running integration tests for security software, or running containers from vendors with poor documentation on what permissions are actually required.

Lastly, this would be useful for tracking down Bottlerocket OS bugs that are due to and overly-restrictive selinux policy, and generating a policy changeset to resolve the issue.

from bottlerocket.

@fheinecke Can you explain more what you aim to accomplish with this package?

from bottlerocket.

Thanks for providing detailed info for your use cases for allow2audit. The primary problem with this package being included in the OS is that it is written in python and we don't include interpreters directly in the OS. Are you able to run this via the admin container?
There is probably a better way to do this, but I edited the audit2allow python script manually to point at where the logs are mounted in the admin container (on line 43) and was able to get it to run:

SYSLOG = "/.bottlerocket/rootfs/var/log/messages"

I know this isn't ideal, but it can at least work around the fact that this is a python script and adding it directly to the OS isn't really a great option.

from bottlerocket.

Are you able to run this via the admin container?

I should be able to run in the admin container, if the --policy flag is passed with the path to the policy files. Python 2.7 is already in this container, as well as semodule, so maybe audit2allow could be added to this container image instead?

from bottlerocket.

I just tested doing this via a new host container to provide this functionality. I created a pretty basic container with this Dockerfile:

FROM amazonlinux:2023

RUN dnf install -y policycoreutils-python-utils systemd

ENTRYPOINT sleep infinity

Then I put this in ECR and pointed my user-data at it:

[settings.host-containers.sleeper]
enabled = true
source = ########.dkr.ecr.us-west-2.amazonaws.com/al23sleephostcontainer:latest
superpowered = true

Then from my control container I hopped in and could debug things:

apiclient exec sleeper bash

And from there I have a working AL2023 install that can look at audit things:

journalctl -D /.bottlerocket/rootfs/var/log/journal/ | grep audit > /var/log/audit/audit.log
audit2allow --policy /.bottlerocket/rootfs/etc/selinux/fortified/policy/policy.31 -v -a -w
<no matches>

Forgive me if I've missed something since I don't use audit2allow but this is a way to provide the troubleshooting you are looking for without actually updating the admin container (which is a separate concern). It should let you basically bring your own troubleshooting container with whatever things you like in it. Does this maybe solve your pain in a different way by providing a way to get the debugging without needing to add things to the host?

from bottlerocket.

Thanks for the testing @yeazelm. Would you mind logging this against the version 33 policy as well (/.bottlerocket/rootfs/etc/selinux/fortified/policy/policy.33)? This policy specifically was where I was hitting an issue - the version of audit2allow available via yum repos in amazonlinux:2023 is old enough that it does not support version 33.

Unfortunately audit2allow hasn't had a version bump in at least 16 years despite semi-regular changes to it, so the only way to test whether a copy of it supports a policy of a given version is to test against a binary policy of that version.

from bottlerocket.