Re: inode security state and cluster file systems

[Casey Schaufler <casey@schaufler-ca.com>]

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@vger.kernel.org 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.