kernel recompilation for better hardening

madaidan · May 20, 2020, 11:57pm

Deny access to overly-permissive IPC objects

anthraxx:master ← madaidan:harden_ipc

opened 11:55PM - 20 May 20 UTC

It's a common error to grant too much permission to these objects, with impact r…anging from denial of service and information leaking to privilege escalation. https://labs.portcullis.co.uk/whitepapers/memory-squatting-attacks-on-system-v-shared-memory/ This creates the kernel.harden_ipc sysctl that when enabled will deny access to overly-permissive IPC objects given the following criteria: 1) If the IPC object is world-accessible and the euid doesn't match that of the creator or current uid for the IPC object 2) If the IPC object is group-accessible and the egid doesn't match that of the creator or current gid for the IPC object Processes with CAP_IPC_OWNER are still permitted to access these IPC objects. This is based on GRKERNSEC_HARDEN_IPC.

Patrick · May 21, 2020, 1:27pm

Not sure that will be sufficient. Package name, kernel headers package, dunno what else could be important.

A deb isn’t a deb repository which is a bit more effort to create.
Signed debs however would also be an option.

madaidan · June 2, 2020, 2:03am

https://blog.herecura.eu/blog/2020-05-30-kconfig-hardening-tests/

HulaHoop · June 2, 2020, 1:47pm

Take two:

github.com/anthraxx/linux-hardened

Deb packages

opened 01:46PM - 02 Jun 20 UTC

closed 03:03PM - 11 Aug 20 UTC

HulaHoop0

Hi. Can you please consider creating debs in an apt repo for releases? This woul…d increase uptake and make the kernel readily usable by downstream distros like us (Whonix). Also when new security fixes are made it will be much faster to get a newer version out for the masses. As far as security goes, everyone will be using auditable and signed builds (if you're using reproducible build infrastructure) that will greatly reduce attacks against dev machines by nefarious actors.

Patrick · June 2, 2020, 6:25pm

Probably not going to fly:

HulaHoop · June 2, 2020, 10:14pm

Then it’s game over for the whole initiative. There isn’t an obvious way to convert arch packages to debs either.

madaidan · June 13, 2020, 7:07pm

Daniel might continue development of linux-hardened again alongside GrapheneOS (like how it was before).

This means it will be revived and new features are going to be actively developed again.

HulaHoop · June 15, 2020, 1:31pm

Yay. I thought he gave up on it from his comments.

jonathanvlan · June 17, 2020, 4:46pm

hi guys , mentioned about IMA Integrity Measurement Architecture
allows greater security , can be automated with one click ,

kernel > ima_policy=appraise_tcb ima_appraise=fix ima_policy=tcb ima_hash=sha512 evm=fix

Debian project, with ima-evm, whonix could include this security

madaidan · June 25, 2020, 6:07pm

HulaHoop · July 29, 2020, 1:44pm

Sony contributes more safeguards against debugFS abuse from userland. The KConf becomes effective in more modern versions.

madaidan · September 4, 2020, 6:26pm

madaidan · November 14, 2020, 7:23pm

We’ve already mitigated exploiting this by non-kernel attackers via apparmor-profile-everything and hide-hardware-info’s sysfs restrictions. However, we can also disable

CONFIG_INTEL_RAPL
CONFIG_PERF_EVENTS_INTEL_RAPL

in the kernel configuration. We could probably disable the entire powercap interface as future-proofing against other variations of this type of sidechannel attack but this may be too extreme and hurt usability (depending on how frequently it’s used, I’m not sure).

github.com

anthraxx/linux-hardened/blob/4.19/drivers/powercap/Kconfig

#
# Generic power capping sysfs interface configuration
#

menuconfig POWERCAP
	bool "Generic powercap sysfs driver"
	help
	  The power capping sysfs interface allows kernel subsystems to expose power
	  capping settings to user space in a consistent way.  Usually, it consists
	  of multiple control types that determine which settings may be exposed and
	  power zones representing parts of the system that can be subject to power
	  capping.

	  If you want this code to be compiled in, say Y here.

if POWERCAP
# Client driver configurations go here.
config INTEL_RAPL
	tristate "Intel RAPL Support"
	depends on X86 && IOSF_MBI

This file has been truncated. show original

Patrick · November 14, 2020, 7:47pm

Probably should not break CPU temperature control. Related:

madaidan · November 14, 2020, 8:53pm

GrapheneOS now enables CONFIG_FORTIFY_SOURCE_STRICT_STRING in production builds:

This is a feature from linux-hardened that I added back to GrapheneOS which makes the FORTIFY_SOURCE feature more strict and better at catching buffer overflows but it wasn’t intended for use in end-user builds, only for bug finding as it can cause false positives so I didn’t enable it before.

github.com/anthraxx/linux-hardened

FORTIFY_SOURCE intra-object overflow checking

committed 06:38PM - 05 Nov 20 UTC

thestinger

+26 -10

This adds supporting for detecting buffer overflows from inner objects for the f…ortified string family functions. It's comparable to the _FORTIFY_SOURCE=2 feature in glibc with the additional coverage of intra-object read overflows for supported functions. The mem* family functions are left with only the inter-object overflow checks as is the case with glibc _FORTIFY_SOURCE=2. This feature is currently hidden behind CONFIG_EXPERT because it's a lot more likely to uncover benign / intended issues and will need a lot of runtime testing. It's already useful for finding bugs but it may not yet be a good idea to use it for hardening unless panics for benign issues are seen as a lesser evil than the vulnerabilities it can catch. Signed-off-by: Daniel Micay <danielmicay@gmail.com>

We should test enabling this too and see if it works. CLIP OS only enables it in debug builds.

Patrick · December 4, 2020, 4:53pm

madaidan · December 5, 2020, 11:39pm

GCC plugins (including STRUCTLEAK, STACKLEAK, RANDSTRUCT and others) may get removed because upstream is being pedantic about a single second difference.

https://lkml.org/lkml/2020/11/28/207

https://lkml.org/lkml/2020/12/1/1832

Of course Linux maintains century old drivers that nobody ever uses but when it comes to actually important security features, they get rid of them at any chance they get. This is ridiculous and quite worrying.

HulaHoop · December 7, 2020, 3:46pm

I am baffled by Kees’ reply who’s supposed to be the checks and balance on stupid stuff like that.

madaidan · December 13, 2020, 5:36pm

Patrick · December 14, 2020, 7:26am

Merged and uploaded to all repositories.