Implementation of Medusa in the Linux kernel (2.[24].x) This part is incomplete; based on 0.7.10 or 0.7.11 implementation. This document will be more like a programmers guide to those who wants to modify the kernel part of Medusa. CONVENTIONS There are 3 layers in the kernel space: hooks in the original kernel code (layer 1) These have to be as small as possible and placed only where it is really necessary. At the beginning of each source file, add: #ifdef CONFIG_MEDUSA #include #endif All they have to do is to call some routines from layer 2 and interpret the return value. They MUST implement correct behaviour for at least 2 return values: MED_OK and MED_NO. They MAY implement MED_YES and/or MED_SKIP. See include files for their meaning. This part is almost complete and would not need to be modified soon. medusa/ directory (layer 2) Contains all the sources, which have to be in kernel space. Generally, there are no restrictions, but keep the portability in mind. This layer implements the routines, which are called from hooks in the original sources (layer 1). They: * do basic permission checks (virtual spaces etc.) * check for cached confirmation information * call the communication layer, if necessary. They must accept MED_ERR from layer 3, and interpret it correctly. Current implementation re-encodes MED_ERR to MED_OK, which ensures `normal' operation of kernel, if there is no authorisation server running. communication layer in medusa/comm.c (layer 3) Communicates with some authorisation server. Currently, it creates a character device to communicate with an user-space daemon. There are many possible communication interfaces, for example authorisation via parallel port, dedicated ethernet card, in-kernel authorisation server (either constable or lisp interpreter to mimic the behaviour of VXE project). This layer serializes the requests, if needed by authorisation server. From the kernel side it provides these functions: int medusa_init(void) char *medusa_request(struct medusa_packet *msg, const char *data) This is subject to change. We are planning to make much more versatile and object oriented interface. Then we will have to re-write some routines in layer 2. After this cleanup, layer 2 will not require further changes if communication part changes. Rewrite of layer 3 will also enable communication speed-up (using only information needed by some action), will help to support multithreaded authorisation daemon in user-space (to speed things up in SMP environment) and so. The interface for adding own communication routines will be smarter too and maybe you will be able to insert layer-3 (or layer-4, as layer 3 will serve only as a gateway between l2 and l4) code as kernel modules.