On Sat, 14 Apr 2001, Crispin Cowan wrote: > 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. I just misinterpreted the name of the list. I dislike the presence of the word "module" in it :) > > 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. That is the point : where is stored a rule like "httpd can't read the logs" when the computer is off ? > > * 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? A good beginning is the permission() and capable calls in the kernel : egrep -r '(permission\(|capable\()' /usr/src/linux/* > > * 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. No exportation is needed : I'm speaking of a function that is part of the kernel itself, that will be the hook at these many places in the kernel, and that will call appropriate functions of a security policy module for it to make the decision. This module would have registered itself before, in its init function, with a security_module_register() function, which is the only to be exported. Am I clearer this time ? (I hope!) > > * 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? I was talking about the thing I called security_module_register(). > > * 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? This is the same issue, but I didn't understand what you proposed to resolve this. I only see the three solutions I proposed, plus a binary patch a la rdev (well, more more complicated, but that the idea) > > * 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. Yes, but what will the recognition rely on ? Path names ? device/inode numbers ? fingerprints ? - fingerprints can't identify changing files (log files, etc.) - pathnames are easily fooled and do not target precisely an object - device/inode numbers identify very well an object but happen to evolve through time (log file rotated, etc.) I think that, even with its drawback, the third is the more secure, and the one that make most sense. And it happens to work not so bad. > > > * 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? I think this could be the cherry on the cake (as we say in french :)). We'll just have to keep it in mind not to close the door when the moment come. Anyway, where do we store logs : on a disk. Usually, into files in the filesystem through klogd, but it could also be on a raw disk, through the network to a remote disk, on a lineprinter,... I think we should do a really-in-the-kernel klogd. Another think is about automated log rotations : if a process can do it, an intruder can do it to, and transform your logs in salami. We could make a klogrotate... But let's focus first on the framewok for security policies! -- Philippe Biondi Systems administrator Webmotion Inc. http://www.webmotion.com mailto:philippe.biondiat_private Fax. (613) 260-9545 _______________________________________________ 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:38:06 PDT