On 2/18/2011 8:25 AM, Stephen Smalley wrote: > On Fri, 2011-02-18 at 10:15 -0600, Yuri L Volobuev wrote: >> The logical place to make this call would be at d_revalidate time. >> The new value of the security context is not readily available at >> that time, as described above. Technically speaking, the file system >> code could know the new context -- it can do a getxattr, which would >> return the up-to-date label content. However, this would require >> knowing the security label xattr name, which is not readily available >> in RHEL6. (I actually had the code working with correct semantics on >> RHEL5, which has security_inode_xattr_getsuffix(), but it would be >> fair to say that it was hacking around the API rather than leveraging >> it as intended). >> >> Hope it makes things clearer. > Yes, thanks. One lingering concern then is that we revalidate > permissions on read/write via security_file_permission -> > selinux_file_permission. Within selinux_file_permission, we check > whether the task SID, inode SID, or policy has changed since the file > was opened, and if so, we recheck permissions. If you only make the > call at d_revalidate time, then we'll only update the inode sid on next > lookup and thus ongoing reads/writes on an already open file will > continue to succeed even if they should be denied by policy until some > process on that node attempts another lookup. Would you be so kind as to move this discussion to linux-security-module@xxxxxxxxxxxxxxx so as to include the LSM community as a whole? Thank you. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
