MPROTECT

[thestinger]

Only extended attribute exceptions need to be supported and it's probably a good idea to use a new one to avoid conflicts with how PaX uses user.pax.flags in the future.

[thestinger]

This is a low priority since SELinux can provide most of the benefits already. A related project would be extending the SELinux memory protections but that's not in scope here.

[theLOICofFRANCE]

You can ask Amon Ott for help for adding RSBAC_MPROTECT in your project. https://www.rsbac.org/pipermail/rsbac/2016-August/002730.html

[thestinger]

MPROTECT isn't in-scope as a downstream linux-hardened change since the bulk of the feature is already present in SELinux.

The description of what you're linking to doesn't sound like an equivalent to this. PaX MPROTECT and SELinux prevent more than mappings with both PROT_WRITE and PROT_EXEC.

The only reason to implement something else is for people not using SELinux.

[thestinger]

Note the out-of-scope label.

[theLOICofFRANCE]

Effectively everyone does not use SElinux (increases only the sense of security otherwise you will not be able to rooted your android phone with KingoRoot and other apk ...)

Yes PAX_MPROTECT is more complete.

But it's a very interesting if you protect PROT_WRITE and PROT_EXEC and I think about your scope ...

[thestinger]

increases only the sense of security otherwise you will not be able to rooted your android phone with KingoRoot and other apk

If you look at things as black and white there's no point of considering any of this. Why even worry about exploit mitigations instead of solving the real problem?

This project isn't going to add more features that are easily done using SELinux policy unless there are substantial contributions from other people and those kinds of features are something they want to implement alongside features without that overlap with SELinux. Minor extensions to SELinux are a lot more maintainable than a whole new LSM with a new configuration system.

If you want this implemented, start working on other features and then work on this frill which could be considered in scope if a contributor to the project wanted it.

[theLOICofFRANCE]

Why even worry about exploit mitigations instead of solving the real problem?

OK, Let's go : https://github.com/copperhead/linux-hardened/issues/51

[thestinger]

I don't really see the connection between what you're quoting and the issue you filed. I think you missed the point of my reply. You're asking for features that can be done with SELinux already, and yet you claim that SELinux is useless since it doesn't prevent all exploits. That implies the mitigations you want are useless too since if you consider them useful you consider SELinux useful...

[thestinger]

Closing in favour of #52 rather than labelling this out-of-scope.

[theLOICofFRANCE]

I am for the principle KISS and avoid the dependency as much as possible. Your new title speaks to me much more. Sorry, English is not my native language ;)

So I understand the direction of your project.

[thestinger]

Developing / maintaining an enormous amount of out-of-tree code to replicate only a small portion of a general purpose feature isn't keeping it simple. SELinux already exists upstream and is well-maintained. Adjusting SELinux policy to enforce all kinds of different mitigations and to lock down access in general is simple. Hard-wiring it all via special-cased code isn't simple and the lack of flexibility presents a major compatibility problem unless there's a flexible system for making exceptions. PaX uses extended attributes for marking exceptions which wasn't flexible enough for Android apps, unlike SELinux, so when CopperheadOS used PaX to provide this feature it had to carry patches to make it possible to make exceptions via groups.

[thestinger]

If you don't want SELinux, okay, but don't pretend that hard-wiring all of the hardening that can be done with special-cased code and extremely fine-grained POSIX permissions is simple or easier to get right. It's the opposite...

I don't see any sense in approaching this via hard-wired code enforcing arbitrary policy decisions in the kernel rather than the flexibility and far greater power offered by existing SELinux policy.

[theLOICofFRANCE]

I don't see any sense in approaching this via hard-wired code enforcing arbitrary policy decisions in the kernel rather than the flexibility

Simply to prevent all bypass. For various reasons many users on centos, rhel, fedora disable SElinux but if all the protections are in the same place ... It's a paradise for getting root rights ^^

Frequently the problem is the user, but there are legion: 1, 2, 3, 4 ...

To avoid over-dependence on a single solution, never putting all your eggs in the same basket. But that is your project and I let you decide here.

[thestinger]

Your reasoning doesn't make sense. PaX MPROTECT can be disabled and has an exception system. Disabling dynamic code generation / modification causes plenty of compatibility issues regardless of the system used to determine the policy. You're making a distinction without a difference.

Security requires work on many fronts, not just implementing a few small features. SELinux covers a lot of ground and it's unrealistic to provide the same mitigations / features without MAC.

To avoid over-dependence on a single solution, never putting all your eggs in the same basket.

Redundant features are not security layers.

[thestinger]

Development time should be spent on the enhancements that are filed in the tracker and not marked as out-of-scope: https://github.com/copperhead/linux-hardened/issues?q=is%3Aissue+is%3Aopen+label%3Atype-enhancement. There isn't development time to burn implementing and maintaining redundant features.

SELinux is extensively used by Android and thus CopperheadOS. The SELinux memory protections are almost on the same level as MPROTECT and can be improved to match it. Rather than having an entirely new system for marking exceptions that's specific to this feature it uses the existing policy system used for everything else. As I mentioned above, the PaX exception system isn't flexible enough for this feature to work for Android apps so it had to be extended. It makes far more sense to use the existing policy system that's flexible enough and already in extensive use...

[thestinger]

I've explained the reasoning and there's no point in complaining about it so I've locked the discussion. linux-hardened will not be reimplementing features that already exist. End of story. It's not my problem if distributions / system administrators are too lazy to adopt the existing features. I maintain CopperheadOS, not Fedora.