VERIEXEC(9) | Kernel Developer's Manual | VERIEXEC(9) |
void
veriexec_init(void);
bool
veriexec_lookup(struct vnode *vp);
int
veriexec_verify(struct lwp *l, struct vnode *vp, const u_char *name, int flag, bool *found);
void
veriexec_purge(struct vnode *vp);
int
veriexec_fpops_add(const char *fp_type, size_t hash_len, size_t ctx_size, veriexec_fpop_init_t init, veriexec_fpop_update_t update, veriexec_fpop_final_t final);
int
veriexec_file_add(struct lwp *l, prop_dictionary_t dict);
int
veriexec_file_delete(struct lwp *l, struct vnode *vp);
int
veriexec_table_delete(struct lwp *l, struct mount *mp);
int
veriexec_flush(struct lwp *l);
int
veriexec_openchk(struct lwp *l, struct vnode *vp, const char *path, int fmode);
int
veriexec_renamechk(struct lwp *l, struct vnode *fromvp, const char *fromname, struct vnode *tovp, const char *toname);
int
veriexec_removechk(struct lwp *l, struct vnode *vp, const char *name);
int
veriexec_unmountchk(struct mount *mp);
int
veriexec_convert(struct vnode *vp, prop_dictionary_t rdict);
int
veriexec_dump(struct lwp *l, prop_array_t rarray);
l is the LWP for the request context.
An optional argument, found, is a pointer to a boolean indicating whether an entry for the file was found in the Veriexec tables.
dict is expected to have the following:
Name | Type | Purpose |
file | string | filename |
entry-type | uint8 | entry type flags (see veriexec(4)) |
fp-type | string | fingerprint hashing algorithm |
fp | data | the fingerprint |
l is the LWP opening the file, vp is a vnode for the file being opened as returned from namei(9). If NULL, the file is being created. path is the pathname for the file (not necessarily a full path), and fmode are the mode bits with which the file was opened.
fromvp and fromname are the vnode and filename of the file being renamed. tovp and toname are the vnode and filename of the target file. l is the LWP renaming the file.
Depending on the strict level, veriexec will either track changes appropriately or prevent the rename.
vp is the vnode of the file being removed, and name is the filename. l is the LWP removing the file,
Depending on the strict level, veriexec will either clean-up after the file or prevent its removal.
Name | Type | Purpose |
entry-type | uint8 | entry type flags (see veriexec(4)) |
status | uint8 | entry status (see below) |
fp-type | string | fingerprint hashing algorithm |
fp | data | the fingerprint |
The “status” can be one of the following:
Status | Meaning |
FINGERPRINT_NOTEVAL | not evaluated |
FINGERPRINT_VALID | fingerprint match |
FINGERPRINT_MISMATCH | fingerprint mismatch |
If no entry was found, ENOENT is returned. Otherwise, zero.
Each element in rarray is a dictionary with the same elements as filled by veriexec_convert(), with an additional field, “file”, containing the filename.
Path | Purpose |
src/sys/dev/verified_exec.c | driver for userland communication |
src/sys/sys/verified_exec.h | shared (userland/kernel) header file |
src/sys/kern/kern_verifiedexec.c | subsystem code |
src/sys/kern/vfs_syscalls.c | rename, remove, and unmount policies |
src/sys/kern/vfs_vnops.c | regular file access policy |
An attacker could potentially overwrite the file contents in the remote host at that point, and force a flush on the local host, resulting in paging in of the files from the disk, introducing malicious code into a supposedly safe address space.
There is a fix for this issue, however due to dependencies on other work that is still in progress it has not been committed yet.
A workaround for this issue is listing all files, under all mounts, you want monitored in the signature file.
March 18, 2011 | NetBSD 6.1 |