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

[Eric Biggers <ebiggers3@gmail.com>]

On Thu, Jan 05, 2017 at 04:04:52PM -0400, Marvin P. wrote:
> 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.
> 

This seems insane for multiple reasons and easily bypassed, e.g. by making a
copy of the "allowed" binary.  Why not use a standard security mechanism such as
UNIX permissions?  For example if your module exposes its API as a device node,
make process XYZ run under a certain user or group, and only give that user or
group access to the device node.

Eric