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. _______________________________________________ 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 Feb 05 2003 - 07:35:40 PST