I first disagree with the idea of making a LKM at any prize. We must do sth modular which will have as a side effect to make it possible to put security policies into a LKM. That should be the same as with binary formats. They are not intended to be LKM (at least because you need at least one) but they can be. Main goal : we have to design a generic framework to be able to use better security policies than the current ones (DAC and capabilities). This framework should permit to change the security policy (-> interface) We don't mind about what these security policies (SP for the sake of my keyboard) will be. But we want them to be powerful enough to include things as fine grained as "syslog can't truncate log files". Do everybody agree that we need AC metadata, in other words, data that is neither stored on the filesystem nor in the file, nor in the kernel ? Do everybody agree that a per-process AC data storing is the right way ? (uids and capabilities are also stored in task_struct) If so, I think we can split the stuff into these 7 parts. Most of them seem independant. * We need to design an interface flexible enough to ask any question, from "can we exec this ?" to "can we allow the load of a LKM ?" "can we allow an ioctl to the DAT ?" This interface may take the shape of a function, like the one Amon Ott called gaci_check(). * We need to place this call to this interface wherever it is needed. Lots of syscalls, VFS calls, socket calls, capable calls ... Part of this work should be a way to "prove" that nothing has been forgotten. * We need to have persistent data mechanisms. -> more generalized utopist mechanism for the whole 2.5 ? -> reading file ? -> user space tool + startup scripts ? * We need a mechanism to recognize a process to assign to it its AC data from the global set of AC data. * We need a way to plug a SP into the kernel. Amon Ott already implemented a demo code. * We need an interface to administrate all that. * At the end, the kernel could provide more efficient logging services than printk. (I won't talk about the controversal LIDS' mailer-in-the-kernel (oops, I just did it :)) Waiting for critics... -- Philippe Biondi Systems administrator Webmotion Inc. http://www.webmotion.com mailto:philippe.biondiat_private Fax. (613) 260-9545
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:24 PDT