Re: inode security state and cluster file systems

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

On 2/18/2011 2:40 PM, Eric Paris wrote:
> Resending adding linux-security-module to the thread.  Sorry if you
> feel lost, you can try to look through the SELinux list history, but
> some of this conversation didn't appear their since people are not
> members.....
>
> I can try to write a review if anyone needs/wants it....
>
> On Fri, Feb 18, 2011 at 5:39 PM, Eric Paris <eparis@parisplace.org> wrote:
>> On Fri, Feb 18, 2011 at 3:42 PM, Yuri L Volobuev <volobuev@us.ibm.com> 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.
>>> Interesting.  With plain Unix semantics, a permission check would be done at
>>> file open time, and wouldn't be repeated at read/write time.  So there's no
>>> attempt by the kernel proper to revalidate the associated dentry/inode prior
>>> to calling read/write fop.  So, if the file owner were to change (for
>>> example), the local inode would not necessarily have the correct owner prior
>>> to a write, which is probably important.  So this is something that
>>> transcends the issue of inode security state per se.
>>>
>>> Another possible approach here, as noted by GFS folks, is to invalidate
>>> inode security state when a lock protecting it is lost.  GPFS could
>>> certainly take that approach as well (it's done already for "regular" inode
>>> state).  In this case, it sounds like kernel/LSM code would be responsible
>>> to refreshing the inode security state when it's needed (although fs code
>>> could also drive this explicitly at d_revalidate time).  I'd be fine with
>>> that approach.
>> I'm thinking about the GFS suggested approach of just 'invalidating'
>> the inode security label.  It presents us with 2 problems I can see up
>> front.  It really seems like filesystems would be upset when the next
>> read/write calls starts running down the ->getxattr() code.  Even if
>> they can handle the locking and such of having getxattr called at
>> random times, most of those calls into the LSM only come with an
>> inode.  But we need a dentry to make said ->getxattr calls.   (I
>> believe this is a broken VFS problem, but the VFS requires a dentry)
>>
>> If we made the invalidation point an explicit refresh of the label at
>> least the filesystems would be able to control both of those
>> problems.....

So far the only case that has been discussed is one in which there
is one security attribute on the file. While we don't have it yet there
are a couple of efforts underway to support multiple concurrent LSMs.
It is also plausible for an LSM to use more than one security attribute
on a given file. An approach based on a secid interface may not work
in either scenario. If you want a comparative example, look at directory
default ACLs, which are important security information, but are nor used
to make access decisions on the object to which they are attached.


>> -Eric
>>
>
> --
> 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.
>
>


--
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.