[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: recommends for apparmor in newest linux-image-4.13



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


Reply to: