On Tue, 2005-07-05 at 09:03 -0700, Chris Wright wrote: > Ugh, so far we'd tried to stay out of each fs as much as possible. Yes, minimizing invasiveness was important especially prior to inclusion of LSM in mainline. But I think the approach of this patch is consistent with: - the fact that we were encouraged to migrate to using security xattrs for security labels for SELinux, and - the fact that security xattrs are now supported natively by the major filesystems, and - the fact that ACL initialization for new inodes is handled the same way. And the patch does try to provide the proper subdivision of responsibility between the security module (compute the new inode label and return it to the fs code) and the fs code (set the label on the new inode so that it can be bundled into the same transaction for filesystems that support them). Not to wander off on a tangent, but I think there are going to be other hooks that will need to be fs-specific, e.g. I think that the filesystem code will ultimately need to map fs-specific ioctls to generic permissions defined by LSM, and then call a LSM hook to check the generic permissions. The LSM file_ioctl hook is too limited in what it can achieve at that level, and we really shouldn't be checking fs-specific ioctls in it at all. But such hooks can hopefully be minimized and the right subdivision of labor can be established between the fs code and the security modules in each case. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Tue Jul 05 2005 - 09:26:28 PDT