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.
> 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.
> 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.
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
