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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
