On Sat, 2015-10-24 at 17:04 +0300, Dmitry Kasatkin wrote: > On Sat, Oct 24, 2015 at 3:28 PM, Petko Manolov <pet...@mip-labs.com> wrote: > > On 15-10-23 20:13:41, Dmitry Kasatkin wrote: > >> On Fri, Oct 23, 2015 at 3:29 PM, Petko Manolov <pet...@mip-labs.com> 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.
His usage of the term "multi-tenant" is not the traditional one of having to protect one tenant from another tenant, but where all tenants are equally trusted. Each tenant is allowed to update their own keys on the .ima_mok/.ima keyrings system and append new rules to the policy. The tenants are protecting against a file of unknown origin from being executed, or possibly accessed. Think of a system owned by a company/university with different departments all wanting to run code on it. Not only does the system owner not want to get involved each time a new piece of code has to be signed, but wants to easily be able to associate the code on the system with a dept. So the system owner delegates authority to the different departments by signing their certificate. Mimi -- 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
