voidveriexec_init(, void)boolveriexec_lookup(, struct vnode *vp)true
if it is, or
false
otherwise.
intveriexec_verify(, struct lwp *l, struct vnode *vp, const u_char *name, int flag, bool *found)VERIEXEC_DIRECTVERIEXEC_INDIRECTVERIEXEC_FILEl 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.
voidveriexec_purge(, struct vnode *vp)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)intveriexec_file_add(, struct lwp *l, prop_dictionary_t dict)dict is expected to have the following:
| file string filename |
| entry-type uint8 entry type flags( seeveriexec(4)) |
| fp-type string fingerprint hashing algorithm |
| fp data the fingerprint |
intveriexec_file_delete(, struct lwp *l, struct vnode *vp)intveriexec_table_delete(, struct lwp *l, struct mount *mp)intveriexec_flush(, struct lwp *l)intveriexec_openchk(, struct lwp *l, struct vnode *vp, const char *path, int fmode)
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.
intveriexec_renamechk(, struct lwp *l, struct vnode *fromvp, const char *fromname, struct vnode *tovp, const char *toname)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.
intveriexec_removechk(, struct lwp *l, struct vnode *vp, const char *name)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.
intveriexec_unmountchk(, struct mount *mp)intveriexec_convert(, struct vnode *vp, prop_dictionary_t rdict)| entry-type uint8 entry type flags( seeveriexec(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.
intveriexec_dump(, struct lwp *l, prop_array_t rarray)
Each element in
rarray
is a dictionary with the same elements as filled by
veriexec_convert(),
with an additional field,
``file'',
containing the filename.
| 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.