On Fri, 24 Aug 2001, richard offer wrote: > With your use of *_precondition() do you think it might be worthwhile > generalising this into various hooks? It seems something that any policy > that needs to store its own data would find useful? I don't know that everyone would want it for their module. The precondition functions actually serve several purposes. Let me explain a little more about those purposes and possible alternatives: 1) As you noted, the precondition functions serve to handle subjects and objects in the system that were created prior to module initialization. Some tasks and objects (e.g. the procfs root inode) are created prior to module initialization even when you compile the module into the kernel, so this is needed even in that case. An alternative would be to traverse the kernel data structures (e.g. the task list and each task's open file descriptors) during module initialization and set the security field at that time for these pre-existing subjects and objects. But I'm not confident that you would be able to easily locate all such subjects and objects (e.g. an open file descriptor might be on a Unix domain socket waiting for delivery to a receiving process), so I prefer using the precondition functions to catch these cases in each hook. Another alternative would be to view all such subjects and objects as being outside the control of your module. But that isn't acceptable for SELinux. Finally, let me note that your ability to determine the correct security attributes for these pre-existing subjects and objects may be limited. The SELinux module tries to do what it can to determine the correct attributes after the fact, but it isn't always successful in the dynamically loaded module case. We recommend always compiling the SELinux module into the kernel. 2) The precondition functions serve to handle objects whose security attributes cannot be fully determined at allocation time. For example, when an inode object is allocated by the kernel, we know nothing useful about the inode, e.g. what kind of object will it represent (a file, a socket, a pipe, etc) and what specific object will it represent (for a file, what is the inode number or pathname?). All we can do in inode_alloc_security is mark the inode unlabeled and save the label of the creating task for later use. If the inode is used to represent a file, then we expect that it will later be caught by the inode post_lookup hook, at which point we can set its security class and security identifier. If the inode is used to represent a socket, then we expect that it will later be caught by the socket post_create hook or the socket accept hook, at which point we can likewise set its security class and identifier. If the inode is used to represent a pipe, it may not be caught until it is actually used for a read or write. Similar issues arise for other kinds of objects, like super_block objects where we do not know enough information at allocation time but will later catch the object in the post_mountroot and post_addmount hooks. Conceivably, we could eliminate the need for precondition for this purpose if we ensured that a hook exists to catch each kind of object at the appropriate point after allocation. For files, we already have post_lookup. For sockets, we already have post_create and accept. For super_blocks, we already have post_mountroot and post_addmount. So pipes are the glaring case where we lack such a hook. 3) The precondition functions serve to deal with cyclical dependencies. Such cycles can be created by dependencies between the module and the file system, e.g. loading the persistent label mapping for a file system or loading the security policy configuration. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 : Mon Aug 27 2001 - 06:39:49 PDT