The first answer that i can think is the patches needed on many packages to support selinux.

In the CentOS world, SELinux is a standard feature and there are a lot of command line tools that contain extra command options to access and modify SELinux contexts. For example, here is a snippet from the man pages for the added features found in the ls command: SELinux options: --lcontext Display security context. Enable -l. Lines will probably be too wide for most displays. -Z, --context Display security context so it fits on most displays. Displays only mode, user, group, security context and file name. --scontext Display only security context and file name. I don't know all the commands that have extra options, but I know find is one of them. Thanks Squall

On 29/10/2013 01:21, Allan McRae wrote:

I'd suggest that someone maintains an unofficial repo with all the packages required to set this up to prove the work required for continual maintenance of this has been done. Then requests could be made to (e.g.) add support to the kernel, providing full details of what is required and if it has any effect on those not using SELinux.

Hi, I've had this on my TODO list for a while but never got to finish it up to the point of having a really functional system as it is quite time consuming (especially the SELinux policy fixing part). But I should have some time for it now so I'll try to make those packages. Impact for non-SELinux users should be rather minimal: * kernel: TOMOYO is already enabled and need explicit boot parameter to operate and so will SELinux once enabled. No major changes here except for a slightly bigger kernel. * userspace: only a very restricted set of packages needs tweaks, but it won't impact performance for non-SELinux users. No major changes here except for slightly bigger packages. Only packagers will be impacted as there are still some patches needed and this could slow down 'core packages' updates when issues arise. But fixes usually comes quite quickly as both Fedora and Gentoo maintain packages with SELinux support. I see a couple of issues that will also have to be resolved for SELinux on Arch to be usable: * It needs some support in pacman, otherwise package updates will be painful; * It needs a proper policy tuned for Arch Linux packages. Filesystem hierarchy differences between Fedora and Arch will prevent us from just applying the Fedora policy to Arch; * Performance comparisons between no-SELinux and disabled-SELinux installations to make sure the impact is minimal. Cheers, Tim

On 10/31/13 at 09:36am, Allan McRae wrote:

On 31/10/13 09:36, Timothée Ravier wrote:

...

On 29/10/2013 01:21, Allan McRae wrote:

...

I'd suggest that someone maintains an unofficial repo with all the packages required to set this up to prove the work required for continual maintenance of this has been done. Then requests could be made to (e.g.) add support to the kernel, providing full details of what is required and if it has any effect on those not using SELinux.

Hi,

I've had this on my TODO list for a while but never got to finish it up to the point of having a really functional system as it is quite time consuming (especially the SELinux policy fixing part).

But I should have some time for it now so I'll try to make those packages.

Impact for non-SELinux users should be rather minimal: * kernel: TOMOYO is already enabled and need explicit boot parameter to operate and so will SELinux once enabled. No major changes here except for a slightly bigger kernel. * userspace: only a very restricted set of packages needs tweaks, but it won't impact performance for non-SELinux users. No major changes here except for slightly bigger packages.

Only packagers will be impacted as there are still some patches needed and this could slow down 'core packages' updates when issues arise. But fixes usually comes quite quickly as both Fedora and Gentoo maintain packages with SELinux support.

Requiring patches not accepted upstream is an immediate blocker.

...

I see a couple of issues that will also have to be resolved for SELinux on Arch to be usable: * It needs some support in pacman, otherwise package updates will be painful;

I'm interested as a pacman developer what support would be needed, but that too is a likely blocker.

...

* It needs a proper policy tuned for Arch Linux packages. Filesystem hierarchy differences between Fedora and Arch will prevent us from just applying the Fedora policy to Arch; * Performance comparisons between no-SELinux and disabled-SELinux installations to make sure the impact is minimal.

Cheers,

Tim

Although I'm not a fan of SELinux, it would be nice if there was a list ( wiki article ) which lists all patches we need to apply on our packages. ( Who providers these patches btw. ) And which policy files we need to ship with our packages -- Jelle van der Waa

On Thu, 31 Oct 2013 11:29:32 +0100 Jelle van der Waa <jelle@vdwaa.nl> wrote:

On 10/31/13 at 09:36am, Allan McRae wrote:

...

On 31/10/13 09:36, Timothée Ravier wrote:

...

On 29/10/2013 01:21, Allan McRae wrote:

...

I'd suggest that someone maintains an unofficial repo with all the packages required to set this up to prove the work required for continual maintenance of this has been done. Then requests could be made to (e.g.) add support to the kernel, providing full details of what is required and if it has any effect on those not using SELinux.

Hi,

I've had this on my TODO list for a while but never got to finish it up to the point of having a really functional system as it is quite time consuming (especially the SELinux policy fixing part).

But I should have some time for it now so I'll try to make those packages.

Impact for non-SELinux users should be rather minimal: * kernel: TOMOYO is already enabled and need explicit boot parameter to operate and so will SELinux once enabled. No major changes here except for a slightly bigger kernel. * userspace: only a very restricted set of packages needs tweaks, but it won't impact performance for non-SELinux users. No major changes here except for slightly bigger packages.

Only packagers will be impacted as there are still some patches needed and this could slow down 'core packages' updates when issues arise. But fixes usually comes quite quickly as both Fedora and Gentoo maintain packages with SELinux support.

Requiring patches not accepted upstream is an immediate blocker.

...

I see a couple of issues that will also have to be resolved for SELinux on Arch to be usable: * It needs some support in pacman, otherwise package updates will be painful;

I'm interested as a pacman developer what support would be needed, but that too is a likely blocker.

...

* It needs a proper policy tuned for Arch Linux packages. Filesystem hierarchy differences between Fedora and Arch will prevent us from just applying the Fedora policy to Arch; * Performance comparisons between no-SELinux and disabled-SELinux installations to make sure the impact is minimal.

Cheers,

Tim

Although I'm not a fan of SELinux, it would be nice if there was a list ( wiki article ) which lists all patches we need to apply on our packages. ( Who providers these patches btw. ) And which policy files we need to ship with our packages

Somehow the talk about LSMs keeps coming back again and again... It does not seem likely that SELinux, even if enabled by default, will be used much. Indeed, we've had AppArmor for over a year now, yet entire related userspace is in AUR, and all profiles have to be hand-written or adapted from OpenSuse or Ubuntu ones... Cheers, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

Hello, guys, I noticed this discussion about SELinux just now... as a current maintainer of SELinux packages in the AUR, let me react. First of all, since I have been very busy lately, I didn't have time to keep the AUR packages up-to-date, and the prospects in the near future don't look very good... So, if there is a willing hand among you, I can pass the maintanence to you, together with offline git repos and scripts I use to keep the packages in sync with [core], if that is of any help to you. Now, to the support of SELinux... To enable it, there are 1) certain changes needed in [core] packages; 2) addition of new packages from SELinux-userspace project; and finally 3) changes in SELinux policy to fit the Arch. 1) as for changes in [core] packages... these are ussually just build options, sometimes a patch is needed from Fedora, which is ususally upstreamed in the next-or-so version. From currently used packages: coreutils cronie findutils linux logrotate openssh pam psmisc shadow sudo systemd util-linux, in their out-of-date state only findutils, pam, and psmisc use those patches. The case of pam is more complicated, since Arch uses pam_unix2, which is not used in Fedora, causing the patch being harder to come by. 2) as for SELinux-userspace and others, the biggest issue is the changes needed due to python3/python2, and setools which is a mess. 3) as for the policy, I never really got there deep enough, but it seems that especially labelling paths have to be changed to respect the status in Arch, so probably a new Arch SELinux policy should be created and maintained based on Refpolicy or Fedora policy with lots of patching of .fc files. Also, for reasons unknown to me, selinux-usr-checkpolicy has to be build with legacy version of flex to successfully build SELinux policy. Hope, this is of some help... Regards, Nicky -- Don't it always seem to go That you don't know what you've got Till it's gone (Joni Mitchell)

Dne Pá 1. listopadu 2013 20.10:12, Timothée Ravier napsal(a):

Hi Nicky,

On 01/11/2013 10:36, Nicky726 wrote:

...

First of all, since I have been very busy lately, I didn't have time to keep the AUR packages up-to-date, and the prospects in the near future don't look very good... So, if there is a willing hand among you, I can pass the maintanence to you, together with offline git repos and scripts I use to keep the packages in sync with [core], if that is of any help to you.

I'm currently updating all the userspace packages to the latest release. I will probably maintain them from now on. You can orphan them in the AUR, I'll adopt them.

I've opened https://bugs.archlinux.org/task/37578 asking for SELinux support in the default Arch kernel, which will simply the process for those who want to try SELinux.

I'll make the built packages available too.

Tim

Hi, Tim, the SELinux packages are now free for taking, best of luck to you. Nicky

On 01/11/13 08:56, Timothée Ravier wrote:

On 31/10/2013 00:36, Allan McRae wrote:

...

On 31/10/13 09:36, Timothée Ravier wrote:

...

Only packagers will be impacted as there are still some patches needed and this could slow down 'core packages' updates when issues arise. But fixes usually comes quite quickly as both Fedora and Gentoo maintain packages with SELinux support.

Requiring patches not accepted upstream is an immediate blocker.

Sorry, I chose my words poorly. I meant two things: * First, patches required for SELinux should be pushed and accepted upstream. I don't know the current state about those. I'll post an update later. * Future core packages releases may require patches to make SELinux work or even make the packages build with SELinux activated. On this front there isn't too much to be concerned of as both Gentoo and Fedora SELinux folks are affected by those issues too and will surely provide patches which we could push upstream if necessary.

It is completely necessary that all these patches are pushed upstream due to the Arch patching policy.

...

...

I see a couple of issues that will also have to be resolved for SELinux on Arch to be usable: * It needs some support in pacman, otherwise package updates will be painful;

I'm interested as a pacman developer what support would be needed, but that too is a likely blocker.

First, as I don't know pacman internals very well, I may say/assume stupid things. Please correct me if that happens.

Among other things, SELinux use labels stored in files extended attributes to do access control. You can reset those attributes to the default values from the policy using the restorecon command tool or using a function in the libselinux library.

However, I suspect that updating packages using pacman will overwrite those attributes, requiring relabeling at each update as we don't know which files had their attributes changed.

What's needed is a switch/option in pacman to restore SELinux labels on both new files and files that have been overwritten during update.

I'll work on a patch once I got a test system running again.

Is this something unacceptable to put in pacman?

Sounds like this should be a post update hook. But we don't have hooks yet... A