On Wed, Feb 05, 2003 at 10:00:23AM -0500, Stephen D. Smalley wrote:
> No. If one were to add such a field, then it would be accessible
> through the ctl_table structure that is already passed to the hook.
It would. But it shouldn't be passed in for the first time.
> You would not replace the ctl_table parameter with the kernel's
> sensitivity hint, since the security module must be able to make its
> own determination as to the protection requirements based on its
> particular security model and attributes. If you only pass the
> kernel's view of the sensitivity, then you are hardcoding a specific
> policy into the kernel and severely limiting the flexibility of the
> security module.
Yes, and exactly that's the whole point of it! The problem with LSM
is that it tries to be overly flexible and thus adds random hooks that
expose internal details all over the place. Just stop that silly no policy
approach and life will get a lot simpler. There's no reason to implement
everything and a kitchen sink in LSM.
Since the kernel's hint is necessarily independent of
> any particular security model/attributes, it will only provide a
> coarse-grained partitioning, e.g. you are unlikely to be able to
> uniquely distinguish the modprobe variable if you want to specifically
> limit a particular process to modifying it. The existing hook
> interface does not need to change.
If you need attributes attached to the sysctl nodes just diable sysctl by
number and use the existing filesystem based hooks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 07 2003 - 22:00:17 EST