Hi,

in theory yes. Practically, SELinux does not really add much to system security.

Here is why I see it this way:

* SELinux is only a toolkit that can block access for system services to open files, read from content they should not be reading from and so on. The kernel only implements the mechanisms but not a policy of what is allowed and what not.

* That policy itself is the huge problem. Most major distribution bring a "standard" one which is called the "targeted" policy. This only has rules for potentially targeted services that are network-facing but does not enroll a policy for everything. So only a small portion of the system is restricted then.

* Most people (according to a RedHat or Fedora survey that I cannot find at the moment) switch SELinux off. It is annoying when you are doing something the author of the policy did not think of before. I know that some large deployments of well-known companies in the cloud switch off SELinux immediately after installation. It is usually the first thing many people do.

Hence this is a useless feature.

And now this is me trying to defend lazy people^^

But security that is not practical is just doomed. People disable SELinux because modification of the rules is a pain. You cannot *easily* create a custom rule or an exception for something. This is maybe only a usability issue...

So here is the reason why we are removing this now:

We always thought that some time down the line we will have a policy that we can adopt and modify for our own use. That SELinux will be more adapted in the world. It is not. And so is no other alternative like AppArmor.

So this is creating a lot of pain. And we do not see that it is worth wasting so much time on it which we just do not have. We are only a very small team and we cannot afford anything like this that is only eating our time with very little output.

So, we are now removing this without any replacement.

Practically, I do not see any reason why this will make the security of an IPFire box weaker. There has not been a single security problem (like Heartbleed, Shell Shock, etc. with or without a name and logo) that could have been prevented by SELinux. Not a single time there was a sentence in the advisories that said "Systems with SELinux enabled" are not affected.

So for me this is nothing more but a glorified chroot environment without a chroot. I think this can be achieved in many other ways as well.

And if we had more time I would be looking into supporting grsecurity again instead of SELinux.

Hope it is coming across what I am trying to say here.

If not or if you disagree, please reply.

Best, -Michael

On Sat, 2016-10-29 at 11:19 -0700, Codermotor wrote:

While I am only an Ipfire user, I like to follow this list to keep up with its development. In that light, I am curious: why is Selinux support being dropped from some of the GNU utilities? Especially since Selinux is one of the best security tools in Linux. Won't removal of Selinux support weaken security in Ipfire?

On Oct 29, 2016 6:47 AM, "Stefan Schantl" stefan.schantl@ipfire.org wrote:

...

Fixes #11211.

Signed-off-by: Stefan Schantl stefan.schantl@ipfire.org

libuser/libuser.nm | 19 +++++++++++++------  1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/libuser/libuser.nm b/libuser/libuser.nm index c0751dc..709d5ea 100644 --- a/libuser/libuser.nm +++ b/libuser/libuser.nm @@ -5,7 +5,7 @@

name       = libuser  version    = 0.62 -release    = 1 +release    = 2

groups     = System/Libraries  url        = https://fedorahosted.org/libuser/ @@ -25,23 +25,30 @@ build         requires                 cyrus-sasl-devel                 glib2-devel -               libselinux-devel                 openldap-devel                 pam-devel                 pkg-config                 popt-devel -               python-devel +               python-devel >= 2.7.12-2         end

+       export LD_LIBRARY_PATH = %{DIR_APP}/lib/.libs

configure_options += \ -               --sysconfdir=/etc \ -               --with-ldap \ -               --with-selinux +               --with-ldap

prepare_cmds                 # Little hack that we don't build documentation that requires sgml2html                 sed -e "s/^SUBDIRS = .*/SUBDIRS = po/" -i Makefile.in         end

+       test +               # Disable tests which requires a running ldap server. +               sed -e "s/tests/default_pw_test//" -i Makefile +               sed -e "s/tests/ldap_test//" -i Makefile

+               make check +       end  end

packages

2.7.4