Re: [RFC] Changing priority of selinux back to optional
Hello Frans, Hello fellow DDs,
Yes, the SELinux stuff doesn't seem to have any currently active
developers. I haven't heard anything from Manoj in months.
I had to stop working on SELinux myself for various reasons; it's not
that things didn't work, but it was a mixture of personal reasons
(mostly lack of time, and no longer being responsible for the servers I
was using SELinux on) but also largely a motivational thing, that I
didn't feel people really cared much about it. Most of the time when
you'd just mention SELinux, people would basically be scared and run
away. This is largely due to FUD efforts by the AppArmor folks, who -
incorrectly - framed SELinux as being overly complex.
Just recently, at the Google Android Developer Thingy here in Munich,
someone (in the informal discussions around dinner) again suggested
something along the lines of automatically creating users to separate
applications that could easily be squashed using the SELinux stuff.
SELinux works the same way uid and gid work, so it just isn't really
that complex. All the difficulties lie in writing good restrictive
policies; and that doesn't get any easier if you do some uid/gid
magic...
Anyway, back to the original topic:
1. I agree that SELinux currently is not in shape for a release. The
packages are seriously outdated, there have been some major changes in
upstream. In particular, the 'targeted' and 'strict' policies have been
merged and only differ by having a 'targeted' module installed. AFAIK.
2. At least libselinux is linked by many of the core packages, and the
package REALLY should be updated nevertheless. However that might
require also updating most of the other packages; I'm not sure about API
compability.
3. In my experience, none of the SELinux librarys or applications were
particularly hard to package/maintain. All the hard work is in
fine-tuning the policy to support all the Debian-specific stuff.
Especially when you need the cooperation of other maintainers, such as
initscripts: http://bugs.debian.org/390067
cron: http://bugs.debian.org/333837
liblzo1: http://bugs.debian.org/336138
All of which have been open in the range of 1.5-2.5 years.
I pushed fixes for some of these issues (e.g. amavis). Usually the best
way is to split out a specific part of the init script (such as the part
doing the backups of /etc/shadow) into a separate script. This is not a
particularly hard change, but you can face a lot of resistance.
So in fact, the situation for SELinux-related bugs not in the actual
SELinux packages is even worse.
So maybe it would be better to actually get some people involved in
SELinux again. It's a pity to see the AppArmor FUD work this well.
(Albeit AppArmor didn't make it into mainstream kernel or Debian, and I
remember having seen some news message last year that Novell stopped
development of AppArmor?)
The AppArmor WNPP bug has been open for months without any message, too:
http://bugs.debian.org/440680
This makes me wonder if we actually have enough developers working on
security infrastructure and the core system in general. Actually I have
the impression in general (not only with respect to security) that we're
losing developer share, but I can't tell you where people are going to
instead. Ubuntu didn't recently strike me as being more attractive, and
their SELinux and AppArmor stuff is as outdated/stalled as ours. It's
mostly Fedora/Gentoo (for SELinux) and SuSE (for AppArmor) that seem to
be doing progress here, but probably only because there are a few single
persons pushing the stuff for the distributions they use themselves.
best regards,
Erich Schubert
--
erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
The future is here. It's just not evenly distributed yet. //\
Die Freunde nennen sich aufrichtig. Die Feinde sind es: Daher V_/_
man ihren Tadel zur Selbsterkenntnis benutzen sollte, als
eine bittere Arznei. --- Arthur Schopenhauer
Reply to: