Le 10/12/17 à 22:21, Theodore Ts'o a écrit :
On Wed, Dec 06, 2017 at 11:24:45AM +0100, Laurent Bigonville wrote:
The SELinux policy could be altered to either run everything that we know is
not ready to be confined in an unconfined domain or put that domain in
permissive (which would result in a lot of denials being logged), so it's
possible to behave more or less the same way as AppArmor depending of how
the policy is designed.
It "could" be altered the same way that anyone "could" modify a
sendmail.cf file. Someone "could" create a program which plays the
game of Go written raw assembly language.
If it "could" be done, why hasn't been done in the past decade?
Everything started by logged-in users is already running unconfined for
years in most distributions (including debian).
For the daemons (httpd,...), the goal was always to have a policy
working well enough so they could be confined, but this requires work to
adjust the policy to work with debian paths and software versions (these
are moving targets).
My idea at some point was to formalize (a subset of) use cases and test
these well enough before enforcing the policy only for these. But I
never had the time to formalize the use cases. Running SELinux all the
domains in permissive doesn't make a lot of sense IMVHO.
It's a bit of chicken-egg problem here, either we confine everything,
things break and we have a high risk of people disabling SELinux or we
put everything in permissive and people doesn't even see that the policy
is not correct. In both case we have no bug reports, well at least that
what I was afraid of and that's and why I personally never proposed
SELinux to be enabled by default.
Also, don't forget that the SELinux team in debian is made of 2 people,
Russel for the policy and I'm taking care of the userspace.
TL;DR: Not enough time/testing/manpower
