On Fri, Jan 22, 2016 at 11:25 AM, Remi Gacogne < firstname.lastname@example.org> wrote:
since I won't get an answer on the forum except "Read the Wiki" which isn't helpful, I ask here. Is here anybody with real world experiences with SELinux on Arch? The forum states the userland tools as "work in progress" which doesn't say anything about the progress… I'd like to know how easy SELinux is to use on Arch. I am just starting out to (re-)enabling it on my CentOS-servers and there it is actually not that hard after all nowadays because of the great tools available. But how about Arch?
You might want to look at this project:
I know Nicolas is working on making it as easy as possible to use SELinux on Arch, and he is doing a great job.
I am this Nicolas :) I am currently maintaining the SELinux packages in the AUR and can answer you with information which is more up to date than the wiki page (that I don't update often, and thankfully other people are taking care of it).
First, about the userspace tools and library (libselinux, setools...) and the programs which need to be recompiled with SELinux support, there are AUR packages which are working (I am not aware of any bug right now, and am using them on my systems). I have been working on making the install process easier for a few years and as there can be some difficulties (like the build-time circular dependency between util-linux and systemd, which is not a bug according to https://bugs.archlinux.org/task/39767), I recently published an install script which builds and installs all SELinux packages (build_and_install_all.sh in https://github.com/archlinuxhardened/selinux). You may be interested in using it to get SELinux on Arch.
Then, about the policy, there is currently no publicly-available policy for Arch Linux, unlike Gentoo, Debian, Fedora and CentOS. For those on the ML which are not familiar with SELinux but who know firewall configuration, SELinux is like a firewall for applications and "a SELinux policy" is a set of rules to filter accesses in a way which is similar to iptables rules filtering network communications. There is an "upstream" (reference) policy, from Tresys Technologies ( https://github.com/TresysTechnology/refpolicy), which is used by Debian and Gentoo (not by Fedora). I am currently working on bringing Arch Linux support into refpolicy, and this work is still in progress. For example refpolicy did not have systemd support before its last release (which happened in December), and now there are still issues with partially-supported systemd services. I recently updated selinux-refpolicy-arch AUR packages with some commits from my personal policy which I'll submit upstream ( https://github.com/archlinuxhardened/selinux-policy-arch/commits/2.20151208), but it is still not complete for a "base system".
By the way, if anyone wants to take a look at what looks like Arch Linux with SELinux, for example in a virtual machine, it is possible to create a Vagrant VM by following the instructions on https://github.com/archlinuxhardened/selinux/tree/master/_vagrant and then play in a "vagrant ssh" session.
Finally, for the reasons why SELinux is not integrated to Arch Linux like Debian (i.e. compiled without being activated by default, contrary to CentOS and Fedora where SELinux is enabled by default), I believe the three main points are:
* support of audit in the kernel (currently there is an annoying bug in chromium seccomp filters which spams the logs when audit is enabled, https://code.google.com/p/chromium/issues/detail?id=456535), * LSM support in the kernel (e.g. https://bugs.archlinux.org/task/37578 , which is more detailed than https://bugs.archlinux.org/task/31448) * and package management (libsepol, libselinux and libsemanage would need to be added to core repository and thus maintained by Arch devs).
I do not see anything today which would lead to the solving of any of these issues in the short run, so I maintain packages in the AUR and continue working on the policy. If you feels like helping this work, feel free to submit pull requests on GitHub (or submit patches upstream).
PS : for the record, I am running a kernel with both SELinux and grsec (without RBAC) on my systems. These two security systems target different things and it is possible to use both.