|| ||Casey Schaufler <casey-AT-schaufler-ca.com> |
|| ||Eric Paris <eparis-AT-parisplace.org> |
|| ||Re: inode security state and cluster file systems |
|| ||Mon, 21 Feb 2011 19:57:05 -0800|
|| ||Yuri L Volobuev <volobuev-AT-us.ibm.com>,
Stephen Smalley <sds-AT-tycho.nsa.gov>, SELinux-AT-tycho.nsa.gov,
Mark Fasheh <mfasheh-AT-suse.com>,
Joel Becker <jlbec-AT-evilplan.org>,
LSM List <linux-security-module-AT-vger.kernel.org>,
Casey Schaufler <casey-AT-schaufler-ca.com>|
|| ||Article, Thread
On 2/21/2011 11:56 AM, Eric Paris wrote:
> On Sun, Feb 20, 2011 at 3:16 PM, Casey Schaufler <email@example.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
>> 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.
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)