8fc0d7a9c3
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. |
||
---|---|---|
.. | ||
Makefile | ||
veriexecctl_conf.l | ||
veriexecctl_parse.y | ||
veriexecctl.8 | ||
veriexecctl.c | ||
veriexecctl.h |