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. -- Stephen Smalley National Security Agency -- 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.
