Re: inode security state and cluster file systems

On 2/21/2011 11:56 AM, Eric Paris wrote:
> On Sun, Feb 20, 2011 at 3:16 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 2/18/2011 2:40 PM, Eric Paris wrote:
>>>> 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.
> I'm still leaning towards a solution in which the filesystem needs to
> tell the LSM that it's labels are invalid (I suggest that be done on
> any change in the security.* namespace) and that same call needs to
> cause the LSM to refresh its labels.  I seem to think that such a call
> would work just fine with any LSM stacker or even
> multi-attribute/multi-label LSM (which uses the security.* namespace).

Yes, this seems completely reasonable and equally annoying for all
concerned. I think that it would be a good idea to pass the name of
the attribute changed (e.g. "SMACK64") so that the LSM(s) can decide
if it(they) need take action.


> The biggest problem is if the 3 cluster filesystems in question can
> handle an interface that requires a dentry

If they can't I think that the LSM can get the dentry from an inode,
although it is not convenient. Hmm. A brief look at code indicates
that this may not be easy for the LSM. So it looks as if the filesystem
might have to pass dentrys.

>  and if they can handle the
> fact that we do permissions checks on read/write and would like those
> operations to start failing immediately if another node changed the
> label.  I really don't see any other way to solve the problem....

Distributed systems are tricky. That's one reason I work in security,
it is so much simpler.

> -Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html