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

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

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

[Eric Biggers]

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