On Tue, 2005-05-24 at 16:56 -0500, serue@private wrote: > But if stacker reads data not in that format from userspace, it sends it > to selinux. Stacker could write selinux's procattr info without a > leading "selinux: " if (a) a boot time arg tells it to, (b) a sysfs > directive tells it to, or (c) it has read data from selinux without the > leading "selinux: " before. I wonder whether, in case (c), we would > generally write to a procattr file before reading one... I don't think so; most programs precede SELinux-related processing by checking is_selinux_enabled(), which both checks /proc/filesystems for "selinuxfs" and checks /proc/self/attr/current for "kernel" (a hack to see whether a policy has been loaded or whether we are still using the initial SID strings). The other options still require explicit changes in userspace to be coordinated with a kernel update for existing releases to avoid breakage. > First, another very respected kernel developer's private auditfs > feedback included asking why the hooks which were next to LSM hooks > weren't using LSM. The answer in this case was that audit must always > run before an LSM. But that sounds to me like the issue for the ima > module itself is still open for debate. I think that was just driven by not wanting to clutter the core kernel with multiple hook calls at the same location. Note that it presumes the same location is truly appropriate for the different purposes, which is not always the case. But when it is the case, it can be addressed by: - calling a single static inline at that location that expands to one, some, or none of the (security,audit,measure,verify) hooks depending on kernel configuration, with a well-defined ordering among them, or - creating a meta-hook infrastructure on which they all rely with a common core of hooks shared by them, or - using SELinux as the shared framework and directly integrating them into it so that they can leverage its policy abstractions as well and serve to reinforce the access controls rather than being redundant. > Second, the other modules are in fact authorization modules, and so > could not use hooks which existed only for measurement. > > Assuming the tpm authorization module was going to be an LSM, are > there reasons why it would not be useful with selinux? What about > digsig? It seems to me that they would be more useful as directly integrated with and reinforcing MAC rather than operating in isolation or trying to replicate functionality that is better provided by MAC. Using MAC for integrity and confidentiality protection at runtime, reinforced using cryptographic mechanisms to protect against bypass of the OS. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 05:38:48 PDT