Christoph Hellwig wrote: > 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. The sysctl hook simply provides a way for a security module to implement a security check for access to sysctl variables. It provides a classic kernel object (ctl_table) x operation interface, with the subject implicitly passed via current, just like permission() for inodes. A security module can leave the hook unimplemented (no restrictions beyond DAC), or implement a purely process-based restriction or implement fine-grained controls to individual sysctls. Sysctls are already exposed to userspace via sysctl(2) and/or /proc/sys, so I'm not sure what the concern is there. Nothing complicated here. As to your argument about LSM's flexibility, LSM simply followed the guidance on what would be accepted into 2.5. The original SELinux/Flask architecture was more tightly integrated and had well-defined boundaries while still providing substantial flexibility, but the response to the SELinux presentation was to move towards something more like LSM. Seems pointless to argue about it now, except as suggestions for future directions for LSM in 2.7. > If you need attributes attached to the sysctl nodes just diable sysctl by > number and use the existing filesystem based hooks. Sorry, I don't see why this is preferable to implementing a single security hook in ctl_perm that is invoked for both sysctl(2) and /proc/sys access, providing a consistent access control regardless of the interface. Your approach is more prone to vulnerability (failing to disable the sysctl(2) interface), and breaking application compatibility. -- Stephen Smalley, NSA sdsat_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 Feb 05 2003 - 08:41:22 PST