The default SELinux policy does not allow passing generic USB devices
and unallocated TTYs to containers. This prevents the Zigbee and ZWave
USB dongles from being usable by their respective container processes.
These SELinux policy rules allow containers to log directly to
syslog/the systemd journal via the `/dev/log` socket. To enable this,
simply mount the socket into a container's mount namespace, e.g. `-v
/dev/log:/dev/log`.
Files and directories that have restrictive permissions and/or are now
owned by *root:root* require `cp` to have additional process
capabilities in order to copy them to the writable filesystem.
The default SELinux policy for Podman only allows it to relabel certain
files, such as `user_home_t`, to `container_file_t`. This effectively
precludes mounting arbitrary directories from `/var` into containers.
Custom builds of Aimee OS can now specify additional paths under `/etc`
that should be writable. This is accomplished by populating a file
named `/etc/aimee-os/writable-etc` with a list of paths. Each line must
indicate the type of file (regular file: `f`, directory: `d`) and the
*relative* path under `/etc`.
As the scope of Aimee OS grows, and other applications are added to it,
the `init-storage` command will have an ever-growing list of file and
directory types to copy from the rootfs image. Originally, I wanted to
explicitly allow it to only copy files that are found in `/var`, but
this will become untenable very quickly. As such, to avoid having to
constantly update the SELinux policy for every new application that
stores anything in `/var` at install time, the `aimee_storinit_t` domain
can now manage all "non-security" files, directories, and symbolic
links. This covers pretty much everything in `/var` except
`/var/log/audit`, while still excluding the most sensitive files (e.g.
`/etc/shadow`),
Rather than hard-code the GPT partition label into the `init-storage`
and `factory-reset` scripts, these now determine the block device by
reading `/etc/fstab` and using the device specified for `/var`.
It turns out that we cannot use `systemd-tmpfiles` to create our Btrfs
subvolumes. Since the directories we are interested in, specifically
`/var/log` and `/var/tmp` already exist in the rootfs image and are
therefore copied into the mutable filesystem, `systemd-tmpfiles` ignores
them.
To avoid having to explicitly specify the SELinux context for each
subvolume created on the persistent filesystem, `init-storage` now
executes `setfiles` to set the appropriate labels.
The `set-root-password` command sets up an alternate mount namespace
with a writable `/etc` directory and then runs `passwd` in it. This
allows `passwd` to create its lock files and backup files, without
requiring that the real `/etc` to be mutable. After `passwd` finishes
and has updated its private copy of `/etc/shadow`, the script rewrites
the real one with its contents.
In order for users to be able to log in locally or via SSH without an
authorized key, they will need to have passwords set in `/etc/shadow`.
We do not really want to make all of `/etc` writable, so we will store
the actual `shadow` file on the persistent data volume, in a separate
Btrfs subvolume, and then bind-mount it at `/etc/shadow`.
While this makes `/etc/shadow` mutable, it does not actually let the
`passwd` program modify it. This is because `passwd` creates lock files
and backup files in `/etc`. We will ultimately need a wrapper to
"trick" `passwd` into modifying `/etc/shadow`, without making the whole
`/etc` directory mutable.
Apparently, BusyBox's `cp` does NOT copy SELinux contexts when the `-a`
argument is specified. This differs from GNU coreutils's `cp`, and
explains why the files copied from the rootfs image to the persistent
storage volume were not being labelled correctly. The `-c` argument is
required.
Now that files are labelled correctly when they are copied, the step to
run `restorecon` is no longer necessary.
In effort to support different builds of Aimee OS using the same
scripts, without necessarily having to fork this repository, the build
system now supports a `CONFIGDIR` setting. When this variable is set,
files defining the target environment, such as the lists of packages to
install, the kernel configuration, the Portage configuration, etc. are
found in the path it specifes.
The reference build, for the Home Assistant Yellow board, is configured
in the `yellow` directory. To build it, run:
```sh
CONFIGDIR=yellow ./vm-build.sh
```
Dustin