in entries for Veriexec.
This has been requested for a long time, most recently by Brad Harder.
Thanks a lot to Michael van Elst for the patch, done during the latest
hackathon.
Obviously, this breaks the already unstable Veriexec ABI, but that's
it. Some cool additions are planned to be introduced, and this just
makes it so that NetBSD 4.0 users will be able to easily use them as
well.
This also removes the fingerprint type name limit, so relevant code
was adjusted.
Thoroughly tested (even uncovered a bug in proplib! thanks for fixing
that cube@!). Documentation updated.
First one was incorrectly loading entries -- we were treating each file as
a mount, which resulted in huge mess. I have no excuse for how I didn't
catch this earlier.
Second, use the table name we create for the Veriexec sysctl node and not
the fixed "table0".
Both are fileassoc(9) integration fallout.
introduce fileassoc(9), a kernel interface for associating meta-data with
files using in-kernel memory. this is very similar to what we had in
veriexec till now, only abstracted so it can be used more easily by more
consumers.
this also prompted the redesign of the interface, making it work on vnodes
and mounts and not directly on devices and inodes. internally, we still
use file-id but that's gonna change soon... the interface will remain
consistent.
as a result, veriexec went under some heavy changes to conform to the new
interface. since we no longer use device numbers to identify file-systems,
the veriexec sysctl stuff changed too: kern.veriexec.count.dev_N is now
kern.veriexec.tableN.* where 'N' is NOT the device number but rather a
way to distinguish several mounts.
also worth noting is the plugging of unmount/delete operations
wrt/fileassoc and veriexec.
tons of input from yamt@, wrstuden@, martin@, and christos@.
We can now delete an entry from the tables using
veriexecctl delete /path/to/file
or remove an entire table using
veriexecctl delete /mount_point
(any directory will work for the mount point it's on)
This closes a hole pointed out by Thor Lancelot Simon on tech-kern ~3
years ago.
The problem was with running binaries from remote storage, where our
kernel (and Veriexec) has no control over any changes to files.
An attacker could, after the fingerprint has been verified and
program loaded to memory, inject malicious code into the backing
store on the remote storage, followed by a forced flush, causing
a page-in of the malicious data from backing store, bypassing
integrity checks.
Initial implementation by Brett Lymn.
- Verified Exec -> Veriexec
- pseudo-device is `veriexec'
- veriexec.conf -> signatures, and mention /etc/signatures as the default
location
- We use veriexec's strict level, not the system securelevel
- Mention the `direct' option
- Mention that the signatures file can have multiple options in a single
entry, comma-separated
- Mention that both `direct' and `indirect' access modes are implied
if no access modes are explicitly mention in the options
- Bump date
- Report line numbers correctly.
- Don't perform a 2nd pass when there are were errors during 1st.
- Support multiple, comma-separated flags. This is mostly a reworking of
some parser internals preparing for planned features.
Use -I${.CURDIR} instead of -I. to support placement of objects elsewhere.
Make sure arguments to ctype functions are unsigned char by changing the
type of one function argument.
Fix "local declaration shadows global" warnings by renaming variables.
Fix printing of size_t variable to use %zu format instead of %u.
* We now use hash tables instead of a list to store the in kernel
fingerprints.
* Fingerprint methods handling has been made more flexible, it is now
even simpler to add new methods.
* the loader no longer passes in magic numbers representing the
fingerprint method so veriexecctl is not longer kernel specific.
* fingerprint methods can be tailored out using options in the kernel
config file.
* more fingerprint methods added - rmd160, sha256/384/512
* veriexecctl can now report the fingerprint methods supported by the
running kernel.
* regularised the naming of some portions of veriexec.
elad