Question: read-only file access in kernel module (verify checksums)

[Marvin P.]

Good day,

    I'm going over some code in a kernel module to implement file access 
functionality in an LKM. I've gone through Grek KH's lengthy article on 
it, and noted the pitfalls (interpreting data, how one should go through 
sysfs instead, etc): all good points and duly noted. I have also opted 
to go with `filp_open()` and `vfs_read()`, and to verify if the file is 
safe to access via `locks_verify_area()`, at the advice of a fellow dev 
who works with file systems.

    One of the policy/legal requirements I have is that "all due efforts 
must be made to only allow process XYZ to access the driver". To 
accommodate this, the md5sum of the userspace process/app that talks to 
the driver/LKM is hard-coded in the kernel module at build time. When a 
process connects to the driver, the full path to the program/binary 
associated with the task is acquired via `get_task_mm()`, `d_path()`, 
etc, and then passed to `filp_open()` and `vfs_read()` to buffer the 
data to the Linux kernel crypto API. If the checksum of the program 
matches what is expected, access is permitted. Otherwise, the process is 
killed and the attempt logged.

    Is it possible to apply an FL_POSIX lock (or file lock in general) 
to the file from the module I'm reviewing, so that I can accomplish two 
things:
1) Make sure the program binary isn't unlinked or altered while the 
module is reading/hashing it, so the module has a guaranteed chance to 
finish reading it.
2) Prevent the program binary from being moved, or the symlink used to 
access it being altered, while the verification is in place (ie: simple 
guard against TOCTTOU attacks). The program lives in /bin typically, but 
is accessed via a symlink in /usr/bin for testing.

Since these checks are made very rarely (unless an unauthorized user has 
root access to the system and is hammering the kernel module), there is 
no concern with it being an expensive operation.

Thank you for your time and assistance.

By Canadian eMail, Nili.ca