Comment by amluto | Hacker News Reader

Comment by amluto | Hacker News Reader

Parent Full thread

> How do you actively detect a malware agent running in user space using stealth or a kernel.

You start with correct design.

The system has a root of trust (ideally you skip the insane level of complexity that is Secure Boot + TPM and use something simple, testable, and verifiable — this isn’t actually that hard). Only authorized images will boot, and, more importantly, nothing else on the network trusts the machine until it proves it’s running the right image.

Then you make the image immutable. Want to edit a system file? You can’t. Maybe in developer mode you can edit an overlay.

All configuration is stored in a designated place, and that configuration is minimized. A stock image from the distro vendor has zero configuration, so there is no incomprehensible soup in /etc to audit. Configuration is also attested.

Persistent data is separate from configuration. All persistent data is considered suspect. Any bug that allows malicious persistent data to compromise anything is a blocker, including corrupt filesystem metadata.

A root-of-trust attestation has limited lifetime. The system forcibly re-verifies periodically. This either means rebooting or doing a runtime “dynamic root of trust” attenuation. The latter is complex.

Complicated messes like kernel “lockdown” and the stock Secure Boot signatures have no place. Usermode root and the kernel are approximately equally trusted. SELinux is barely necessary, if at all, unless the actual user code wants it to control access to persistent data. But there are simpler, better schemes that are easier to reason about.

Sadly the industry doesn’t think this way. I’m regularly surprised that Apple hasn’t gone in this direction more aggressively than they are with their MacOS products.

You haven't answered anything interesting. Any software system that anyone cares about operates on state - user documents, a database, other bespoke systems etc. If the operator of that system accidentally deploys malware to it, how to you ensure that this malware doesn't destroy, replace, or exfiltrate this state the the system normally operates on?

Malicious code doesn't need to run as root in order to completely destroy a business.

Not to mention, all of the things you describe are very nice if the kernel is perfectly secure. But it's not, so it's always possible and even likely that compromising any user on the system is equivalent to compromising root. And if you compromise one system, you can then exploit bugs in other systems' kernels that might allow RCE through well-crafted packets or other exploits that gain access without running through any user-space code that might validate those attestations.

And finally, when a vulnerability is found allowing such exploits, you now need to update all of these readonly systems - and this happens at least once a month. Do you go with a USB stick to each of 10k systems on five continents to update them?

This kind of smug "I know better than the rest of the industry, security is easy if you do things my way" is rarely productive or applicable.

What you've answered is a great (if not the best) way to defend against attackers, but not what was asked,They asked how to detect.

I'll strongly disagree on selinux, I have seen it work in practice to defeat attackers many times, that provide features that seccomp and cgroups etc do not.

re: SELinux, I think it depends on your use case.

If your system is a flight information display, then you may well have two userspace processes that do anything of significance: the display manager and the actual app. There is no persistent state. At this point, SELinux is purely overhead and extra attack surface — what would it even protect.

If your payload is a container (database server, microservice, whatever), and you’re doing some form of best-practice volume management, then only the database’s own data is mounted for it. SELinux is a real PITA to get working in a context like this, and it’s not really clear what it would add. (Okay, maybe you get fancy and use it to restrict what can talk to the microservice. Or maybe you use network namespaces.)

If you’re running a desktop or a more conventional server setup, then, sure, MAC policy has its place.

Absolutely depends on the use case. I'm attempting to talk in the generic case. If you limit policy to the minimum attack surface from outside the process including permissions and capabilities which are significantly more fine grained in selinux compared to normal Unix permissions, you reduce the the capability of the attacker once they gain access to the system.

Imagine if they got access to local code execution... Binding to sctp protocol would instantiate the whole protocol in kernel. Effectively opening up whole new attack vectors. I can't see any other techniques (other than selinux like AC) that enables this kind of attack space reduction as easily.

I am aware that you can blacklist modules,etc but this is just one of many examples.

You can use SEccomp for some of it as well. But for SEccomp something in the hierarchy needs to do this actively

While SELinux can be set up somewhat orthogonal to the running system. OTOH systemd should make it easy to confirm every service process

For this sort of kernel attack surface reduction, I would use a combination of seccomp and runtime module loading restriction.

In the specific example of sctp, one can turn off loading of modules at runtime entirely.

> Only authorized images will boo

How do you do this on modern commodity hardware without secure boot?

Or do you assume something in the category of embedded systems that allow to blow some efuses to get similar trusted boot?

> How do you do this on modern commodity hardware without secure boot?

It’s not necessarily easy without Secure Boot, sadly. The actual straightforward solution is boot ROM. It would be nifty if someone made SD cards, eMMC devices and such meant for this use case for independent use. Most Android vendors manage to use boot ROM.

Reply on news.ycombinator.com