Talk:SELinux

Custom Kernel Advice

Under the section about Preparing the kernel the artile says:

"Warning: If you've built a custom kernel which is not linux-selinux (e.g. linux-ice or linux-pf), then the various packages which have to be compiled may fail to do so because of the linux-selinux dependency. Make sure to remove that dependency while compiling those packages. However, be careful that the options mentioned above are enabled in your kernel configuration."

Wouldn't it make more sense to advise people to properly set the provides and conflicts variables in their custom pkgbuild instead of manually removing a dependency from every other pkgbuild that relies on it? Tjwoosta (talk) 20:25, 7 December 2013 (UTC)

Well, it actually does make more sense. The various SELinux packages should not depend upon this kernel (linux-selinux, that is). However, it really is the easiest solution to all this trouble. The packages assume that an SELinux enabled kernel is present on the system. However, the only kernel in both the official repos as well as the AUR to support SELinux out of the box is this kernel. I wrote that warning to remind people that they need to be running a kernel compiled with SELinux support. - Genghizkhan91 (talk) 07:09, 3 January 2014 (UTC)

Regarding linux-selinux

There is no need for the package any more, methinks, seeing that the SELinux LSMs are enabled now in the kernel. Hence, I am changing the status of linux-selinux in Siosm's table to deprecated, seeing that the official kernel package now includes support for it by default. - Genghizkhan91 (talk) 07:05, 6 February 2014 (UTC)

Regarding systemd-selinux

The last time I tried installing the latest systemd in the official repos (compiling it with selinux support, of course), I found there to exist an ordering cycle which does not exist normally (i.e. without selinux support compiled and the audit daemon). I wrote this warning for it:

Warning Another way to install systemd is by getting the official PKGBUILD file and making the changes as shown above. However, as of the current version of systemd (204-2) in the official repos, running the audit daemon (auditd.service) causes the creation of an ordering cycle on basic.target causing certain sockets and services to fail. The current version of selinux-systemd in the AUR is 203-1 which has no problems of this sort.

Has this problem been resolved with the current version of systemd in the AUR? - Genghizkhan91 (talk) 07:13, 3 January 2014 (UTC)

Regarding installation via AUR

Someone needs to do this and see if it works as written here or whether some of the steps (especially downgrading swig) are still required. - Genghizkhan91 (talk) 08:14, 3 January 2014 (UTC)

This should not be required anymore. I've built the setools PKGBUILD against the current version of swig. I'll update this part as soon as I get a working system. Siosm (talk) 02:50, 18 January 2014 (UTC)

Refpolicy instructions are unclear / out-of-date

Both selinux-refpolicy-arch and selinux-refpolicy-src haven't been updated since 2023. I'm having issues trying to use selinux-refpolicy-arch even with firefox (https://github.com/SELinuxProject/refpolicy/issues/843#issuecomment-2564084872).

When I try to install selinux-refpolicy-git, I get:

>>> Building refpolicy-git policy store. Please wait... Failed to resolve roletype statement at /var/lib/selinux/refpolicy-git/tmp/modules/400/unconfined/cil:5 Failed to resolve AST /usr/bin/semodule:  Failed!

It's unclear to me what the 'vanilla' or starting approach is supposed to be. In https://github.com/archlinuxhardened/selinux/blob/master/build_and_install_all.sh it installs all three packages.

However given the age of the packages, it looks to me like only -git is being updated and that's the one the wiki should use. Obviously someone with more knowledge who has this working should weigh in. (: Spease (talk) 10:51, 29 December 2024 (UTC)

Paths in refpolicy not matching

I had to change some paths since they don't match what the policy expects:

semanage export|grep fcontext
fcontext -D
fcontext -a -f f -t NetworkManager_exec_t '/usr/lib/iwd/iwd'
fcontext -a -f f -t rtkit_daemon_exec_t '/usr/lib/rtkit-daemon'
fcontext -a -f f -t switcheroo_exec_t '/usr/lib/switcheroo-control'
fcontext -a -f f -t devicekit_power_exec_t '/usr/lib/upowerd'
fcontext -a -f f -t power_profilesd_exec_t '/usr/lib/power-profiles-daemon'
fcontext -a -f f -t games_exec_t '/usr/bin/steam'

Perhaps this should be added to instructions? Topimiettinen (talk) 10:56, 22 August 2026 (UTC)

Plasmalogin

Plasmalogin didn't want to transition to user domain, so I had to append /etc/selinux/refpolicy-git/contexts/users/user_u with:

system_r:plasmalogin_t        user_r:user_t

However, this change is overwritten on package update. Is this the correct place? Topimiettinen (talk) 11:03, 22 August 2026 (UTC)

An update should leave a .pacnew file and not overwrite it, like with any other /etc configuration. Maybe you needed to run restorecon -v on it after the configuration. Note we use the talk pages to troubleshoot/discuss specific article content. --Indigo (talk) 16:42, 23 August 2026 (UTC)

I guess the problem is that the file is not marked as %BACKUP in pacman files list for the package.

But should I add some text proposing to change the file to instructions in the article? Topimiettinen (talk) 11:14, 24 August 2026 (UTC)

Frankly, the info for the singular package would be rather disjunct in the article. I think it could be massively improved with the general approach to fix problems. E.g. I don't know why the policy does not use a backup array. Perhaps, it is meant to be customised differently (local modules, priorities overriding default policy), or maintainers expect users to submit individual issues.

I think for the article as is it would be better to clarify the general approach and describe it here (see also #Refpolicy instructions are unclear / out-of-date). If no-one with better insight of the status replies to your items soon, it is probably best to ask for the approach via an AUR comment or on github. With an answer we should document that first, to save everyone time figuring it out. --Indigo (talk) 18:16, 24 August 2026 (UTC)

Thanks for the pointers, I'm new to Arch! Topimiettinen (talk) 11:21, 25 August 2026 (UTC)