- make fileassoc_t a pointer and remove FILEASSOC_INVAL.
- clean up kern_fileassoc.c. unify duplicated code.
- unexport fileassoc_init using RUN_ONCE(9).
- plug memory leaks in fileassoc_file_delete and fileassoc_table_delete.
- always call callbacks, regardless of the value of the associated data.
ok'ed by elad.
handle a single entry and veriexec_table_delete() to handle an entire
table. veriexec_convert() now takes a struct vnode *, and made
veriexec_table_lookup() take struct mount * (that's entirely internal
now).
Tested on amd64, built successfully on amd64, i386, sparc, and sparc64.
for work on some future functionality.
- Veriexec data-structures are no longer exposed.
- Thanks to using proplib for data passing now, the interface
changes further to accomodate that.
Introduce four new functions. First, veriexec_file_add(), to add
a new file to be monitored by Veriexec, to replace both
veriexec_load() and veriexec_hashadd(). veriexec_table_add(), to
replace veriexec_newtable(), will be used to optimize hash table
size (during preload), and finally, veriexec_convert(), to convert
an internal entry to one userland can read.
- Introduce veriexec_unmountchk(), to enforce Veriexec unmount
policy. This cleans up a bit of code in kern/vfs_syscalls.c.
- Rename veriexec_tblfind() with veriexec_table_lookup(), and make
it static. More functions that became static: veriexec_fp_cmp(),
veriexec_fp_calc().
- veriexec_verify() no longer returns the entry as well, but just
sets a boolean indicating whether an entry was found or not.
- veriexec_purge() now takes a struct vnode *.
- veriexec_add_fp_name() was merged into veriexec_add_fp_ops(), that
changed its name to veriexec_fpops_add(). veriexec_find_ops() was
also renamed to veriexec_fpops_lookup().
Also on the fp-ops front, the three function types used to initialize,
update, and finalize a hash context were renamed to
veriexec_fpop_init_t, veriexec_fpop_update_t, and veriexec_fpop_final_t
respectively.
- Introduce a new malloc(9) type, M_VERIEXEC, and use it instead of
M_TEMP, so we can tell exactly how much memory is used by Veriexec.
- And, most importantly, whitespace and indentation nits.
Built successfuly for amd64, i386, sparc, and sparc64. Tested on amd64.
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@.
