On Tue, 5 Jun 2001, Chris Wright wrote: > > True, but we can add our own authoritative hooks to support finer-grained > > distinctions. > > Yeah, this is what I'm a tad nervous about. We start having multiple hooks > in the same area doing roughly the same checks. Yes, we will definitely want to be conservative in adding such hooks. But trying to merge our hooks with the existing capable() calls seems difficult, as I've mentioned previously, since we often want more information than is available at that point, and it increases the likelihood of breaking the existing capability semantics. > No, that's not what I meant. Two flavors of hooks. The capable() hooks > being permissive/authoritative, and our additional hooks being > restrictive/authoritative. I am only concerned about the clarity of the > interface since people need to be able to make sense out of it and code > to it. I like the idea of building some kind of uniformity into the > interface. If you throw away the capable() hook (and leave capabilities unchanged in the kernel), then you lose the ability to leverage all of the work done by the Linux-Privs project for your security module. Inserting our own hooks at every location a capable() call currently exists (or replacing every capable() call with our own hooks) just doesn't seem practical to me. You also lose out on being able to sell LSM as a means of removing the capability logic from the base kernel, allowing the Linux-Privs developers to evolve their implementation easily, and allowing capability-haters to substitute a superuser module. So I don't see this as a viable option. We should be able to keep the set of LSM hooks much smaller if we leverage the existing capable() function. > How do we define which hooks take an extra parameter and get to override > the DAC checks? And once we go this route, is there any benefit to mixing? > Why not just use approach #3 and give all hooks the option (forever in search > of a uniform interface ;-). This could allow capabilities to stay in the > kernel as is. In many cases, there won't be any kernel decision to pass to the hook. For example, the inode create hook doesn't have any corresponding kernel decision. The kernel decision for file creation was computed by permission(), which was called by may_create(), so it is sufficient to pass that decision to the permission() hook and let it be authoritative. In other cases, it may be impractical to colocate the kernel decision with the hook call. It seems more confusing to provide the extra parameter even when there is nothing to pass. -- 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 : Wed Jun 06 2001 - 06:42:40 PDT