On 15-10-26 22:39:28, Dmitry Kasatkin wrote: > > We had some discussion with Mimi and could not come to conclusion..
No problems there: truth springs from argument amongst friends. > Can you please still explain when multiple policy writers can content? I 100% > understand the role of mutex.... Ignore the high level requirements for the moment. Every time you have a contended resource you need to protect it from concurrent writers. IMA policy is read way more frequently than it is been written. Just once in the past, now a few times more. This consideration makes it ideal candidate for using RCU. However, we still need some locking to prevent concurrent writes. Instead of adding expensive spin_lock()s when adding the rules to the current policy i figured it would be even easier if we block potential writers at policy file access level. There is one other trick though - the new policy rules are being added to another, temporary list. Both lists, the current policy and the new rules are being spliced after all RCU readers exit the critical section. If there is a syntax error the splice does not happen at all. > But I somehow can not get your use case of when it may be so that multiple > writers add rules at the same time.. > > Can you please give real example of rules to add and why it happens at the > same time. I guess you may want to read http://kernsec.org/files/lss2015/ima-applications-slides.pdf As Mimi put it in one of her emails there _are_ use-cases when a machine is shared between multiple organizations. Neither the vendor nor the tenants want to go through the hassle and sign every package update. This caused the introduction of a certificate hierarchy as well as making IMA policy writable by others. Since you can't remove the original rules and the policy is been scanned as a FIFO we should be as secure as possible given the above requirements. > Concern here is not technical, but purely security related. Technical issues may very quickly become security issues so i'm happy to discuss both. Petko -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
