On 2/21/2011 11:56 AM, Eric Paris wrote: > On Sun, Feb 20, 2011 at 3:16 PM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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 -- 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.
