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.
using both the rawio_spec and passthru actions to detect raw disk
activity. Same for kernel memory policy.
Update documentation (no longer need to expose veriexec_rawchk()) and
remove all Veriexec-related bits from specfs.
* XXX: This is bogus. There's an obvious race condition between the time
* XXX: the disk is open for writing, in which an attacker can access a
* XXX: monitored file to get its signature cached again, and when the raw
* XXX: file is overwritten on disk.
* XXX:
* XXX: To solve this, we need something like the following:
* XXX: open raw disk:
* XXX: - raise refcount,
* XXX: - invalidate fingerprints,
* XXX: - mark all entries with "no cache" flag
* XXX:
* XXX: veriexec_verify:
* XXX: - if "no cache", don't cache evaluation result
* XXX:
* XXX: close raw disk:
* XXX: - lower refcount,
* XXX: - if refcount == 0, remove "no cache" flag from all entries
XXX: We still install rmd160.h and sha2.h in /usr/include/crypto, unlike
the other hash functions which get installed in /usr/include for compatibility.
Make some "#ifdef DIAGNOSTIC" blocks always compiled in; others
convert to KASSERT() where appropriate.
Add some sanity checks and comments while here.
fileassoc.diff adds a fileassoc_table_run() routine that allows you to
pass a callback to be called with every entry on a given mount.
veriexec.diff adds some raw device access policies: if raw disk is
opened at strict level 1, all fingerprints on this disk will be
invalidated as a safety measure. level 2 will not allow opening disk
for raw writing if we monitor it, and prevent raw writes to memory.
level 3 will not allow opening any disk for raw writing.
both update all relevant documentation.
veriexec concept is okay blymn@.
- adapt to NVERIEXEC in init_sysctl.c.
- we now need "veriexec.h" for NVERIEXEC.
- "opt_verified_exec.h" -> "opt_veriexec.h", and include it only where
it is needed.
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@.
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.
VOP_GETATTR() fills a struct vattr, where va_fsid and va_fileid (device
and inode..) are typed as long.
Add some casts when using these values and surround them with XXXs about
the potential size mismatch, as long can be 64 bits but dev_t and ino_t
are always 32 bits. This is safe because *for now* we're still using
32 bit inode numbers.
Discussed with blymn@.
- Change #ifdef VERIFIED_EXEC_VERBOSE to another verbose level, 2. Add
sysctl(3) bits.
- Simplify access type conflict handling during load. This depends on
the values of access type defines to be ordered from least to most
'strict'.
in the veriexec table entry; the lookups are very cheap now. Suggested
by Chuq.
- Handle non-regular (!VREG) files correctly).
- Remove (no longer needed) FINGERPRINT_NOENTRY.
- Better organize strict level. Now we have 4 levels:
- Level 0, learning mode: Warnings only about anything that might've
resulted in 'access denied' or similar in a higher strict level.
- Level 1, IDS mode:
- Deny access on fingerprint mismatch.
- Deny modification of veriexec tables.
- Level 2, IPS mode:
- All implications of strict level 1.
- Deny write access to monitored files.
- Prevent removal of monitored files.
- Enforce access type - 'direct', 'indirect', or 'file'.
- Level 3, lockdown mode:
- All implications of strict level 2.
- Prevent creation of new files.
- Deny access to non-monitored files.
- Update sysctl(3) man-page with above. (date bumped too :)
- Remove FINGERPRINT_INDIRECT from possible fp_status values; it's no
longer needed.
- Simplify veriexec_removechk() in light of new strict level policies.
- Eliminate use of 'securelevel'; veriexec now behaves according to
its strict level only.
elad