From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f65.google.com ([74.125.83.65]:33778 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932204AbdAGE17 (ORCPT ); Fri, 6 Jan 2017 23:27:59 -0500 Received: by mail-pg0-f65.google.com with SMTP id 194so1337852pgd.0 for ; Fri, 06 Jan 2017 20:27:59 -0800 (PST) Date: Fri, 6 Jan 2017 20:27:56 -0800 From: Eric Biggers To: "Marvin P." Cc: linux-fsdevel@vger.kernel.org Subject: Re: Question: read-only file access in kernel module (verify checksums) Message-ID: <20170107042756.GB575@zzz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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