Comments (16)
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.
from linux-hardened.
You can ask Amon Ott for help for adding RSBAC_MPROTECT in your project.
https://www.rsbac.org/pipermail/rsbac/2016-August/002730.html
from linux-hardened.
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.
from linux-hardened.
Note the out-of-scope label.
from linux-hardened.
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 ...
from linux-hardened.
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.
from linux-hardened.
Why even worry about exploit mitigations instead of solving the real problem?
OK, Let's go : https://github.com/copperhead/linux-hardened/issues/51
from linux-hardened.
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...
from linux-hardened.
Closing in favour of #52 rather than labelling this out-of-scope.
from linux-hardened.
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.
from linux-hardened.
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.
from linux-hardened.
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.
from linux-hardened.
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.
from linux-hardened.
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.
from linux-hardened.
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...
from linux-hardened.
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.
from linux-hardened.
Related Issues (20)
- struct layout randomization for Clang
- probabilistic return address protection for Clang HOT 1
- add the option of using -fsanitize=local-init for Clang kernel builds HOT 2
- STACKLEAK for Clang
- figure out how serious Google is about implementing SafeStack + CFI for the kernel and a rough timeline as it can aid an alternate CFI implementation HOT 1
- [Request] Add TCP Stealth system to protect unadvertised servers from port scanning HOT 1
- refcount_t: saturated; leaking memory HOT 1
- stack clearing
- type-based CFI for indirect calls
- type-based CFI for returns
- Why is AppArmor not enabled? HOT 1
- zfs load-keys results in KP HOT 3
- invalid opcode. list_del_entry_valid HOT 4
- Compiling error with version 4.14.13 to version 4.15.1 HOT 6
- CVE-2017-5753 - Spectre Variant 1 HOT 12
- detected buffer overflow in strlen HOT 11
- missing compiler check for "-fsanitize=local-init" support HOT 11
- SROP mitigation with SipHash-generated cookies
- [PATCH] remove unused softirq_action callback parameter - causes build failure on 4.17
- 4.16.13, 4.14.45, 4.14.46, 4.14.47 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from linux-hardened.