grsecurity forums

I saw some mention of MD5 and SHA hashes which seemed to be an attempt to do Tripwire on the fly... which I understand would be resource intensive.

However, after reading about MS'es Palladium ideas, I still like the idea of signing binaries as a way of stopping hackers from tampering.

I haven't thought this completely out, but I wanted to see if this is workable...

I am imagining a binary signing system that uses a private key made from some bit of information built into the hardware which is not available to the typical user, like a CPU serial number or that ID Intel put on systems a few years ago to track identities. In order for an ELF binary to run, it must have to have a valid public key related to the executable's checksum. All runnable binaries would have to be generated by a specially patched linker... and obviously only root would be able to run the linker. In order to initially create all the binaries on the system, the user would have to boot a special kernel.

I'm thinking this would be less resource intensive and more secure, as there is no database of keys that are vulnerable. Sure, it would be possible to brute force the private key, but it would require building alot of dummy executibles and trying to run them, slowing the malicous and alerting the sysadmins.

I'm probably overlooking something simple, but I'd like to hear feedback on the pros and cons... and if this is beyond the scope of GRSecurity.

I still don't understand why this would be needed. What do you gain from this that you don't gain by simply enforcing that your binaries be read only, and not allow execute access to areas writable by the users?

-Brad

Palladium is a bad thing. The last thing we need is hw manufacturors and software monopolies teaming up making proprietary hardware for proprietary closed source operating systems. Especially with Microsoft's recent push with DRM type things.

Computers have always given us the basic power to do with the hardware that we own as we wish. Palladium is the antithesis of this.

spender wrote:I still don't understand why this would be needed. What do you gain from this that you don't gain by simply enforcing that your binaries be read only, and not allow execute access to areas writable by the users?

let me add my two cents, as i see this topic has popped up a few times already. what i see people not to be clear about is the issue of 'threat model' vs. 'defense mechanism'. that is, whenever one establishes a defense, he does it in order to protect against some kind of threat. when we are talking about executable image authentication, the implicitly assumed threat model is that an attacker can somehow tamper with the file system and such tampering would then be detected by verifying some cryptographically secure signature. the problem with this is that it is not a precise model. in particular, it makes another assumption in that the attacker can tamper with the filesystem but not tamper with the signature verification mechanism. in the unix world one would say that the attacker can gain the privileges of some trusted user (who has write access to the target file) but cannot compromise the kernel itself (where the verification would take place). however based on this assumption one can have a simpler and less resource intensive defense: first, make sure that executable files (libraries included) are writable by (at most) a specific user only, and second, no other user is able to assume the privileges of that user. this is the route that grsecurity takes (in simplified terms at least). and if we don't assume the correctness of the kernel, then it does not matter whether we have cryptographic signatures or ACLs in the first place, both can be compromised.