[PATCH][RFC][0/22] - Kernel Generalized Event Management
[Posted April 19, 2006 by corbet]
| From: |
| Bob Bennett <Robert.Bennett-AT-ca.com> |
| To: |
| kernel-mentors-AT-selenic.com |
| Subject: |
| [PATCH][RFC][0/22] - Kernel Generalized Event Management |
| Date: |
| Thu, 30 Jun 2005 10:11:30 -0400 |
| Cc: |
| kgem-devel-AT-lists.sourceforge.net |
| Archive-link: |
| Article,
Thread
|
Following are a set of patches which provide a mechanism for allowing
access control rules to be evaluated from user space. I have attempted
to build this in such a way that there is some flexibility in the data
that is associated with a particular security event. The main kernel
module, gem_main_mod, exports a set of functions that can be called from
an LSM to signal occurrence of a security event and get a response from
the listener, and also registers a special filesystem, kgemfs, which is
used by the user space application to send and receive data. This patch
also includes a module, gem_hook_av_mod, which registers with LSM and
provides on-access virus scanning ability for an Anti-Virus application
in user space. A third module, gem_av_func_mod, defines kernel callback
functions for the events, so an event may be evaluated in the kernel
first before passing down to user space. This allows us to maintain
exclude lists and cache previous results to reduce the overhead of
passing events to user space. It also defines a set of ioctls that can
be used to update exclude lists.
In the future we are looking at developing an LSM that provides a more
comprehensive set of events which can be used to support a user space
based access control system.
I am interested in any comments regarding whether something like this
could have any chance of being accepted, and if (likely(not)), how could
it be improved to have a better chance of acceptance. KGEM is designed
to be an entirely optional component, so if it is configured as modules,
there is no active kernel code until the modules are loaded.
The patches will be sent as a reply to this post.
Thanks,
Bob Bennett
(
Log in to post comments)