NACK: Re: [SRU][X][PATCH 0/1] Provide AppArmor flag indicating binfmt_elf_mmap change

[Steve Beattie]

On Wed, May 29, 2019 at 08:52:12PM -0500, Tyler Hicks wrote:
> On 2019-05-29 18:26:55, Steve Beattie wrote:
> > [Regression Risk]
> > 
> > Low, introduces a new file in the apparmor securityfs filesystem, no
> > other kernel side behavioral changes.
> 
> I think the regression risk is a little more than meets the eye here.
> Introducing a new file in apparmorfs will cause a policy cache
> invalidation and full policy recompilation when initially booting a
> kernel that includes this change. This will happen because the on-disk
> /etc/apparmor.d/cache/.features will not match the new apparmorfs
> layout.

That is correct.

> This used to be an issue in the phablet days because a full policy
> recompilation took a long time on a phone (> 1 minute, IIRC). We don't
> typically do anything to invalidate the cache during the life of a
> stable release but I don't think we'll run into any problems these days.
> The only thing that gives me a little pause is image based stuff (cloud
> and core). However, it might be worth a quick discussion with John and
> Jamie before we apply this patch to see if they can think of any
> potential problems. Can you do that and reply with the outcome?

Yes, I raised this issue, and it was pointed out that, while the phablet
isn't an issue anymore, there are other low-power devices out there for
which an unnecessary[1] total policy compilation would be unpleasant.
So I am withdrawing this patch.

Thanks for the review and raising the issue!

[1] Unnecessary in that the resulting policies would be no different
    than the cached versions.

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20190531/56aec814/attachment.sig>