lkml.org 
[lkml]   [2017]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectQuestion: read-only file access in kernel module (verify checksums)
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

\
 
 \ /
  Last update: 2017-01-05 19:51    [W:0.022 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site