On Sat, Oct 24, 2015 at 5:04 PM, Dmitry Kasatkin <[email protected]> wrote: > On Sat, Oct 24, 2015 at 3:28 PM, Petko Manolov <[email protected]> wrote: >> On 15-10-23 20:13:41, Dmitry Kasatkin wrote: >>> On Fri, Oct 23, 2015 at 3:29 PM, Petko Manolov <[email protected]> wrote: >>> > >>> > I was actually going to get rid of IMA_FS_BUSY. It is less flexible with >>> > respect to user-space tools. If the flag is up then the policy upload >>> > will >>> > fail. The user script or program must check the error and repeat the >>> > operation after some time. Seems kind of pointless to me, unless i am >>> > missing something. >>> > >>> > With a semaphore the second process will block and write the policy once >>> > the >>> > first writer leave the operation. No need to repeat it unless there's >>> > some >>> > real error. >>> > >>> > I was trying to be careful and not break the code in case the new >>> > functionality is not selected in Kconfig. However, with your most recent >>> > patch-set i guess we'll have to revisit a few things. :) >>> >>> Obviously in original situation it will be only a "single" policy writer - >>> which IMA init script or binary. If some other script tries to write policy >>> at >>> the same time I would consider it as someone exploit would trying to do >>> nasty >>> things. >> >> You've got a point here. If we get rid of the busy flag we'll have to block >> at >> open() instead of write() in order to keep the "original" semantics. >> > > No, that was not my point. > The point was that there is no another/simultaneous policy writer in reality. > >>> With possibility to update policy I also do not see any need for multiple >>> writers, when second waits first to finish update and it is not aware about >>> coming another update. It would be some integrity manager doing policy >>> updates >>> sequentially from time to time. >> >> Nope, that's not the only scenario. Imagine a machine with multiple tenants >> and >> huge uptime. Imagine also that these tenants want to run their own software >> on >> this machine. Policy write may occur at any time. >> > > No, I cannot imagine that unrelated processes can write/update policy > simultaneously at any time. > I can imagine that some device/system management software does policy update. > > May be you could give more exact use case. >
Petko, We had some discussion with Mimi and could not come to conclusion.. Can you please still explain when multiple policy writers can content? I 100% understand the role of mutex.... 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. Concern here is not technical, but purely security related. Thanks, Dmitry > >>> But with "reading" the policy file, I could imaging process blocking to wait >>> when update/read completes. >> >> We don't need mutexes to safely read the policy. The code that does list >> splicing is taking care of the reader either seeing the original policy or >> the >> new one. Not a disjointed version of it. >> >> Whether one will see the old or the new policy is a matter of timing and >> semaphores are not going to change this. >> > > Indeed. > >> >> Petko > > > > -- > Thanks, > Dmitry -- Thanks, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
