Current status of the project

Hello, hope your day's going great. I'm currently developing a security and privacy focused linux distribution based on Arch Linux called Prism OS.

Currently Prism OS uses AppArmor as the default MAC system and linux-hardened as the kernel. The linux-hardened kernel disables the creation of unprivileged user namespaces by default meaning programs which genuinely require It like bubblewrap or the chromium sandbox would need to be SETUID. This Is a severe security degradation.

The solution for this would be to revoke the ability to create unprivileged user namespaces globally for all programs and selectively allow programs to create unprivileged user namespaces. However, this can not be done since Arch Linux currently does not apply patches from canonical on any of it's officially supported kernels meaning that the 'kernel.unprivileged_userns_restriction' Is not available. Issue #11 stating the exact problems was created on October of 2024 on linux-hardened source tree, however till now the patch has not been added most probably because features already provided by SELinux are out-of-scope. Thus, my only options are maintaining my own kernel source tree, using selinux as the default MAC system for Prism OS or to change the base to a something like Fedora. I'd definitely prefer the second option.

My question Is If this project currently Is stable enough to be used on a system which will be daily drived? And what Is the current status of official selinux support on Arch? Also It would be great If packages were signed:)

[fishilico]

Hello,

Thanks for reaching out and explaining your context. It is great to see people maintaining security-focused Linux distributions 😃

Is stable enough to be used on a system which will be daily drived?

This depends on what you expect. Using SELinux (in enforced mode) has been working well for me for years for:

• CLI-based systems with small amount of services/applications (for example servers for websites, emails, IRC... where I interact through SSH). Here, a strict SELinux policy works fine.
• Desktop systems with an unconfined policy, where the main user is not constrained but applications and services are (for example NetworkManager, the DNS resolver service... are confined by SELinux policy but not my development environment).
  • For information, the main computer I am using to upgrade https://github.com/archlinuxhardened/selinux and test things has been configured like this for more than 10 years.

In the past, there were issues with systemd, as the SELinux Reference Policy did not support it (and Fedora has been using their own forked policy). This was fixed a few years ago, mainly thanks to Debian switching to systemd if I remember correctly.

A few years ago there were some issues with Podman because it expects Fedora-specific things on systems using SELinux (cf. #109). I don't know whether these issues still exist.

And what Is the current status of official selinux support on Arch?

For a long time, the Arch Linux maintainers refused to enable any LSM (Linux Security Module) in the default kernel. This project packaged linux-selinux in the AUR, which was "linux with SELinux enabled". This changed in 2018 and now enabling SELinux only requires adding a parameter to the kernel command line.

As you can see in this repository, several packages need to be rebuilt with SELinux support (systemd, pam... the full list is in base_pkglist.txt). To make SELinux available "as-is" in Arch Linux, packages such as libsepol and libselinux need to be adopted in repository core... which is not likely to happen any time soon. So we have to stick to the AUR.

Also It would be great If packages were signed :)

A few years ago, someone added in the GitHub Actions CI some mechanics to automatically publish a release with all built packages as a standalone package repository. Signing packages means this CI need to be modified, with a GPG private key in the Actions Secrets:

selinux/.github/workflows/main.yml

Lines 187 to 202 in 6e3c1b6

	- name: Get the SELinux packages from build job
	uses: actions/download-artifact@v4
	with:
	name: Arch Linux packages for SELinux support
	path: /tmp/boots/repo
	- name: Create package repository files
	run: |
	sudo /tmp/boots/usr/bin/arch-chroot /tmp/boots /bin/bash -c \
	'repo-add /repo/selinux.db.tar.xz /repo/*'
	- name: Upload the ready repository as an artifact
	uses: actions/upload-artifact@v4
	with:
	name: SELinux pacman repository
	path: /tmp/boots/repo

There is actually another issue related to this: #127 . If you have some time to work on this (for example if you know how to sign many packages at once from a CI pipeline), please submit a Pull Request :)

It's unfortunate to hear that official SELinux support for arch is not going to be soon. I can not integrate SELinux until a fine grained reference policy for arch Is developed. Using the default wouldn't mean much.

I'm going to create a custom kernel, applying patches from linux-hardened, kernel.unprivileged_userns_restriction sysctl patch from canonical and additional patches enabling some of these sysctls by default. This would give me more flexibility, this would have been eventually done anyways so will save me time In the long run.

A few years ago, someone added in the GitHub Actions CI some mechanics to automatically publish a release with all built packages as a standalone package repository. Signing packages means this CI need to be modified, with a GPG private key in the Actions Secrets. There is actually another issue related to this: #127 . If you have some time to work on this (for example if you know how to sign many packages at once from a CI pipeline), please submit a Pull Request :)

Oh. Unfortunately I do not know how to write git workflows, I'll see what I can do by skimming the docs!