On Tue, 5 Feb 2002, Antony Edwards wrote: > prohibitively) expensive. If that turns out to be true I think > removing sys_read/sys_write hooks isn't such a bad idea -- is anyone > using them? And if so, how are you dealing with memory mapped files? Since SELinux controls descriptor creation, inheritance and transfer, the only potential use for the file_security_ops permission hook for SELinux is to support revocation upon policy changes or file relabels. At present, since the hook exists, the SELinux module uses this hook to revalidate access on read, write, sendfile, and readdir calls. Of course, rather than revalidating access on use to support revocation, the module could simply traverse the appropriate portion of the kernel state (possibly maintaining additional back pointers to help this traversal)and revoke descriptors appropriately when the policy change or file relabel event occurs. Hence, there is no strong reason to retain the file_security_ops permission hook for this purpose. We have not yet implemented support for revocation of access to memory-mapped files upon policy changes or file relabels in the SELinux security module. This is a known area that we would like to address in the future. However, as with revoking descriptors, I think that this can be addressed by having the module traverse the appropriate portion of the kernel state rather than inserting additional hooks. In conclusion, the file_security_ops permission hook does not appear to be justified for revocation purposes. However, it may be useful for privilege bracketing purposes. I view SubDomain's "subprocess" confinement concept as being a variant of privilege bracketing, with the difference being that it is designed to be nondiscretionary for the "subprocess". -- 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 Feb 06 2002 - 06:29:12 PST