Philippe Biondi wrote: > 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. Yes, that's the goal. > Main goal : we have to design a generic framework to be able to use better > security policies than the current ones (DAC and capabilities). Sort of. We have to design a generic interface that exports enough kernel functionality to allow security developers to go off and create these better security policy modules. > 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". That's a conjecture. I propose the pragmatic approach of providing enough functionality to support a variety of existing security enhancement systems, and incrementally extend the module interface as necessary. I understand the value of the "syslog can't truncate" idea, but instead of a priori saying "we have to do this and that", I'd like to look at the candidate modules, and see what they need. > 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 ? I'm not sure what you mean. "Can LSMs be stateful?" Sure, why not? But that's trivial, so its probably not what Philippe meant. A much more dicy question is the interface between security modules that expect AC metadata to be stored in the file system, and file systems that support extended attributes (e.g. can store an access control list associated with a file). We don't want the security module interface to only work with exotic file systems, but we also don't want the security module interface to preclude using the security-enhancing features of exotic file systems. > Do everybody agree that a per-process AC data storing is the right way ? > (uids and capabilities are also stored in task_struct) Yes, I agree with that: * It's what Linus suggested * Our module (SubDomain) needs it * I suspect that LIDS and Janus need it * SELinux, TE, and DTE probably need it > 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(). "Ask *any* question" seems a bit broad :-) Can you narrow that down? > * 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. Impossible. You end up exporting the entire kernel. Better to add exported things to the interface when a module comes along that needs it. > * We need to have persistent data mechanisms. > -> more generalized utopist mechanism for the whole 2.5 ? > -> reading file ? > -> user space tool + startup scripts ? Is this the same issue as my extended attributes comment above? Or is it something else? > * We need a mechanism to recognize a process to assign to it its AC data > from the global set of AC data. Hook exec() and fork(), and let the module decide whether the newborn is something that needs policies applied to it. The "recognition" is itself a policy that should be delegated to the modules. > * We need a way to plug a SP into the kernel. > Amon Ott already implemented a demo code. How is this different from the normal way of loading a security module? > * We need an interface to administrate all that. Delegate to the modules. > * 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 :)) Delegate to the ... (hmmm :-) ... Modules that want to do extended auditing and logging (imagine a BSM module http://www.securityfocus.com/focus/sun/articles/bsmaudit1.html ) should do their own decision making about what is to be logged, and do their own formatting. But they need an efficient path out of the kernel, so that they can put it some where. Does such a path exit? Or do we have work to do here? Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sat Apr 14 2001 - 13:41:02 PDT