FS#15612 - better support for selinux
Attached to Project:
Arch Linux
Opened by Michal Svoboda (pht) - Tuesday, 21 July 2009, 06:34 GMT
Last edited by Paul Mattal (paul) - Thursday, 26 November 2009, 15:20 GMT
Opened by Michal Svoboda (pht) - Tuesday, 21 July 2009, 06:34 GMT
Last edited by Paul Mattal (paul) - Thursday, 26 November 2009, 15:20 GMT
|
Details
Description: Please include support for SELinux out of the
box so Arch can be used on systems where people do mean
security. I attempted to tweak my Arch install for selinux
thus:
1) I installed all the selinux packages only to find out that the refpolicy sources and accompanying userland programs are outdated badly 2) I tweaked and makepkg'd manually all the new packages only to find out that the udev daemon fails to perform its role because it was not compiled with --enable-selinux (or so) and perhaps because /dev is on ramfs instead of tmpfs 3) I worked around all this but then I found out that the refpolicy does not have arch linux as its distro option and a lot of stuff just does not work (take initscripts as an example) 4) I spent some more time with it but then I gave up |
This task depends upon
Closed by Paul Mattal (paul)
Thursday, 26 November 2009, 15:20 GMT
Reason for closing: Deferred
Additional comments about closing: Deferred per Gerardo and bug submitter.
Thursday, 26 November 2009, 15:20 GMT
Reason for closing: Deferred
Additional comments about closing: Deferred per Gerardo and bug submitter.
Personally I don't think SELinux is nice - because of its complexity.
When it comes to security - I'd be more interesting in SMACK support - because of its simplicity.
As for SMACK vs SELinux it would be best if both were supported just as we don't stick to one version of shell, etc.
1) Have all necessary tools support SELinux or provide SELinux enabled alternative packages (for example, there is init, but not udev)
2) Provide updated SELinux userspace packages
3) Submit patches to the reference policy so that 'arch' is a valid DISTRO option ... this will require mainly to set correct paths for the initscripts, etc.
4) After 3) is done provide policy packages in BINARY form (not source)
http://mailman.archlinux.org/pipermail/aur-general/2009-November/007200.html