On Mon, 2005-01-31 at 11:13, Serge E. Hallyn wrote: > selinux.patch: Stacker support for SELinux. Now also removes > the secondary_ops support In selinux_vm_enough_memory(), you wouldn't want to call the top-level capable() even aside from the PF_SUPERPRIV flag issue (which is minor), because that would trigger a call back to selinux_capable() and generate spurious audit messages. Options would seem to be to call cap_capable() directly from selinux_vm_enough_memory() or just drop selinux_vm_enough_memory() entirely. It isn't overly useful until such a time as we actually have policy constructs for resource management based on roles and domains. > stacker.patch: Main change is that, since mod_reg_security() > actually calls verify(ops), all ops->hooks which were > not defined will be pointing to the dummy hooks, so > there is no reason to check > if (m) > m->hook(); > so stacker now just calls m->hook(). This might provide > some performance improvement, particularly if the > m->hook call was on the path requiring the jump. (I > haven't checked that). The question is whether verify should be called on secondary modules, as you might otherwise end up calling the dummy module's hook function multiple times if two or more of the stacked security modules fail to define the hook. > stack-capabilities-with-selinux.patch: A new patch which > implements changes needed to enable explicit stacking of > capabilities and SELinux. I would particularly appreciate > feedback on these: > > 1. Introduces noop versions of setxattr, removexattr, > vm_enough_memory, netlink_send, and netlink_recv. > Unlike the dummy versions, these truly do nothing. Looks like noop_netlink_send is obsoleted by your change to stacker to intersect the results, and noop_netlink_recv could be avoided by dropping selinux_netlink_recv (which is identical to dummy/cap_netlink_recv anyway). An obvious side effect of selinux-stack.patch is that you must enable stacker and cap_stack if you want to preserve normal capability checking with SELinux; otherwise, SELinux will be authoritative with respect to capabilities. At present, even if you don't enable capabilities, SELinux ends up stacking itself with dummy, so you at least get the normal uid 0 checking for capabilities. Hence, if these patches were to be upstreamed in their current form, I think we would want the Kconfig logic to automatically select stacker and cap_stack when SELinux is enabled, or at least default them to enabled if SELinux is enabled. This would also mean that the performance and scalability overhead of stacker has to be minimal, as it would effectively become a dependency for normal use of SELinux. That may require revisiting the locking scheme for the chained security objects. -- Stephen Smalley <sds@private> National Security Agency
This archive was generated by hypermail 2.1.3 : Mon Jan 31 2005 - 12:40:06 PST