SOLDIERX.COM Nobody Can Stop Information Insemination

We're excited to announce the release of secadm version 0.2! We've been working hard on a new star feature: Integriforce.

You can download secadm 0.2 here and the GPG signature here. It was signed with Shawn Webb's GPG key with fingerprint 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE.

Change Log:

• New feature: Integriforce. executable file integrity through hash checking and enforcement
• Fix issue linking with prior versions of secadm
• Fix typos
• Various cleanups

Announcing Integriforce

This feature provides executable file integrity enforcement. If a rule exists for a given file, that file's hash as defined in the rule is matched against the hash of the file. If the hashes don't match, execution may be disallowed, depending on the configuration settings. Integriforce is an optional, but powerful, feature. Integriforce currently supports SHA1 and SHA256. Both executables and shared libraries are supported. Please note that files that are under Integriforce management cannot be modified or deleted. The ruleset will need to be flushed prior to modifying or deleting the file.

When we did our call for testing (and thank you to those who tested!), only executable files were checked, not their dependencies (shared objects). With HardenedBSD v18 (sysctl hardening.version) and secadm 0.2, we now support checking the dependencies. This required a change in the runtime linker (also known as the RTLD) that calls into Integriforce if it is available. Additionally, there is a new kernel feature sysctl exposed, kern.features.integriforce.

For the past few weeks, I've been working on a new feature for HardenedBSD's secadm project. secadm is short for Security Administration and is built to control the various exploit mitigation features we're developing in HardenedBSD. I'm currently writing a feature I've termed "Integriforce", short for "integrity enforce." It's very similar in concept to NetBSD's Veriexec feature.

In secadm's configuration file, you list the executables you want to make sure verify to a certain hash along with the hash. You can specify two modes: soft or hard. Soft means that execution is allowed even if the hashes don't match, but a warning message is logged. Hard mode disallows execution if the hashes don't match along with logging an error message.

As it stands right now, verification of shared objects an application depends on is not happening. We are investigating how to do that while still giving reasonable performance. One possible solution is to check the hash on every call to open(). We would cache the modified time (mtime) of the file. If the file hasn't been modified since its first hash check, then we already know the state of the file. If the file has changed (mtime differs), then rerun the hash calculation and update the cache. This would be expensive on both the CPU side and the disk side, especially given the mutexes/locks needed to maintain multicore/multiprocessor safety. Now each call to open() would require acquiring at least one lock, possibly two.

We've completed our first milestone and are preparing to release secadm 0.2-rc1 within the next couple weeks. Verifying the integrity of applications using SHA1 and SHA256 are currently supported. The second milestone will be released as secadm version 0.3. That will include ELF binary signing with x509 certificates, similar to how PE files can be signed.