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.

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

docs: Talk more about runtime properties, especially SELinux #473

Merged
merged 1 commit into from
Apr 17, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
63 changes: 63 additions & 0 deletions docs/src/building/bootc-runtime.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,3 +61,66 @@ Relevant links:
- [CentOS Automotive SIG unattended updates](https://sigs.centos.org/automotive/building/unattended_updates/#watchdog-in-qemu)
(note that as of right now, greenboot does not yet integrate with bootc)
- <https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/>


## Kernel

When run as a container, the Linux kernel binary in
`/usr/lib/modules/$kver/vmlinuz` is ignored. It
is only used when a bootc container is deployed
to a physical or virtual machine.

## Security properties

When run as a container, the container runtime will by default apply
various Linux kernel features such as namespacing to isolate
the container processes from other system processes.

None of these isolation properties apply when a bootc
system is deployed.

## SELinux

Container runtimes such as `podman` and `docker` commonly
apply a "coarse" SELinux policy to running containers.
See [container-selinux](https://github.com/containers/container-selinux/blob/main/container_selinux.8).
It is very important to understand that non-bootc base
images do not (usually) have any embedded `security.selinux` metadata
at all; all labels on the toplevel container image
are *dynamically* generated per container invocation,
and there are no individually distinct e.g. `etc_t` and
`usr_t` types.

In contrast, with the current OSTree backend for bootc,
when the base image is built, label metadata is included
in special metadata files in `/sysroot/ostree` that correspond
to components of the base image.

When a bootc container is deployed, the system
will use these default SELinux labels.
Further non-OSTree layers will be dynamically labeled
using the base policy.

Hence, at the current time it will *not* work to override
the labels for files in derived layers by using e.g.

```
RUN semanage fcontext -a -t httpd_sys_content_t "/web(/.*)?"
```

(This command will write to `/etc/selinux/policy/$policy/`)

It will *never* work to do e.g.:

```
RUN chcon -t foo_t /usr/bin/foo
```

Because the container runtime state will deny the attempt to
"physically" set the `security.selinux` extended attribute.
In contrast per above, future support for custom labeling
will by default be done by customizing the policy file_contexts.

References:

- <https://github.com/ostreedev/ostree-rs-ext/issues/510>