AppArmor for Complete System - Including init, PID1, Systemd, Everything! - Full System MAC policy

[Patrick]

@madaidan

unless debian provides a glibc-hardened-malloc package or similar.

Seems very unlikely.

• RFP: hardened-malloc – hardened memory allocator
• glibc feature request - consider using Hardened Malloc
• debian glibc feature request - consider using hardened malloc (hardened memory allocator)
• glibc-alpha mailing list - consider using Hardened Malloc
• Hardened Malloc - Hardened Memory Allocator - #50 by Patrick

@madaidan

I’m thinking of using apparmor’s environment scrubbing on all binaries although that would break using LD_PRELOAD for hardened_malloc.

Also, using a different environment for apt is not enough. Attackers can still write to /etc/ld.so.preload and other /etc/ld.so.* files so everything preloads their malicious library, including apt even with a new environment.

But, using environment scrubbing and disallowing writing to /etc/ld.so.preload will prevent us from using hardened_malloc at all unless …

Users could boot into admin mode (without apparmor-profile-everything) and configure /etc/ld.so.preload?

We could allow root to run a yet to be invented script which copies a file /etc/ld.so.preload_template to /etc/ld.so.preload.

/etc/ld.so.preload_template would have the following contents:

/usr/lib/libhardened_malloc.so/libhardened_malloc.so

That way while apparmor-profile-everything is enabled, root could enable hardened malloc but not configure an arbitrary (malicious) /etc/ld.so.preload?