search

anthraxx / linux-hardened

Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: irc.libera.chat #linux-hardening
Other
566 stars 56 forks source link

Photon OS hardening patches #29

Open madaidan opened 4 years ago

madaidan commented 4 years ago

VMware's Photon OS includes a few extracted PaX features. MPROTECT, RANDKSTACK and RAP.

https://github.com/vmware/photon/blob/master/SPECS/linux/0001-NOWRITEEXEC-and-PAX-features-MPROTECT-EMUTRAMP.patch

https://github.com/vmware/photon/blob/master/SPECS/linux/0002-Added-PAX_RANDKSTACK.patch

https://github.com/vmware/photon/blob/master/SPECS/linux/0003-Added-rap_plugin.patch

It could be a good idea to include these in linux-hardened. I'm not able to review and submit these patches myself though.

Bernhard40 commented 4 years ago

mprotect was supposed to be handled by S.A.R.A lsm however development of it stalled.

RAP is too hard to maintain without full knowledge of it and keeping it in sync with every new mainline release would be rather futile.

madaidan commented 4 years ago

I haven't seen any activity on S.A.R.A. since 2017 so having MPROTECT here makes a lot of sense.

Bernhard40 commented 4 years ago

You didn't seen it all then, last patch is from July 2019.

The patches you linked above are from early 2017 though.

madaidan commented 4 years ago

Ah, thanks. I couldn't find anything past 2017.

theLOICofFRANCE commented 4 years ago

@madaidan

so having MPROTECT here makes a lot of sense.

From @thestinger (2017)

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.

https://github.com/AndroidHardeningArchive/linux-hardened/issues/52

theLOICofFRANCE commented 4 years ago

@Bernhard40

hout full knowledge of it and keeping it in sync with every new mainline release would be rather futile.

VMWARE supports version 4.19, nothing prevents you from taking it only in the 4.19-lts branch.

Bernhard40 commented 4 years ago

Back in the days linux-hardened was mostly targeted for android which uses SELinux extensively. This is not the case for generic linux platform so adding MPROTECT improvement make sense .

VMWARE supports version 4.19, nothing prevents you from taking it only in the 4.19-lts branch.

I neither trust of vmware maintaining big grsecurity plugins on their own and linux "lts" releases which misses hundreds of security fixes.

thestinger commented 4 years ago

Back in the days linux-hardened was mostly targeted for android

That's not really true.

This is not the case for generic linux platform so adding MPROTECT improvement make sense .

It doesn't make sense to have this project make changes overlapping with existing LSMs.

SELinux is how these access control mechanisms are implemented upstream, along with many important forms of kernel attack surface reduction, not just userspace access control.

It's also important to keep in mind that non-anonymous mappings bypass MPROTECT and you need an access control mechanism to handle them. You don't necessarily need a Mandatory Access Control implementation but it's the most direct way to handle all of this.

thestinger commented 4 years ago

The point of this project was implementing kernel self-protection and userspace process hardening which does not overlap with what should be done via LSMs or in userspace. It's not intended to replace hardening elsewhere in the OS. If you want to use linux-hardened as it was intended, you need to pair it with full system SELinux policies, verified boot, a hardened libc and compiler toolchain.

It's also important to note that the intention is using Clang including using Clang's upstream forward-edge Control Flow Integrity implementation along with ShadowCallStack on arm64 (there is no equivalent on x86_64 at the moment, due to the unfortunate way x86 handles returns). These aren't yet available upstream, but they're broadly deployed downstream. Clang CFI + ShadowCallStack are used on the Pixel 3, 3 XL, 3a, 3a XL, 4 and 4 XL along with other mobile devices.

https://outflux.net/blog/archives/2019/11/20/experimenting-with-clang-cfi-on-upstream-linux/

Hopefully it will finally land upstream.

thestinger commented 4 years ago

The goal of linux-hardened was never supposed to be providing redundant features better accomplished via SELinux or work in userspace. For example, beyond the base randomization provided by the kernel for the mapping it creates, most related hardening belongs in libc in the malloc implementation, linker, etc. If you're simply using linux-hardened with glibc, without full system SELinux policies, without compiler hardening features like CFI deployed and so on then you aren't using it as it was intended. It's supposed to be a minimal patch set only doing things in the kernel which make sense there. Trying to implement tiny portions of what a proper access control policy provides via hard-wired, inflexible mechanisms was never within the scope of the project.

Piling on tons of overlapping features is a problem rather than a solution. MAC/MLS are important and are the only way to systemically approach many things in a way that's complete and also flexible enough for real world deployment. If you want to do those things, just do them upstream, not in linux-hardened, which was meant to take a saner approach to security than piling on incomplete, redundant features everywhere and chasing after security as something to address with long lists of features.

I haven't been actively involved in it for years now because the community was incredibly apathetic and not interested in contributing to development work. @anthraxx has kept it alive and well maintained but some bits and pieces have rotted away and there hasn't really been any substantial active development work. The project never really took off the ground.

Everything you need to disallow running dynamic native code is available via SELinux already and you can extend that to distrusting persistent state via proper verified boot too. You should really just start over with the policies rather than bothering with the poor approach taken by most desktop and server distributions.

Bernhard40 commented 4 years ago

It doesn't make sense to have this project make changes overlapping with existing LSMs.

As I said the most plausible is adding this feature through separate SARA lsm in upstream. I didn't said it should be linux-hardened feature.