Clock set to past confuses AppArmor cache validation

I've thought about this quite a bit and I don't think there is anything we can do in AppArmor for this. The profiles simply need to have an mtime that is earlier than the cache files. Trying to hack around it in scripts trying to guess the state of the system relative to the clock would be brittle. However, adjusting the mtime in the files in /var/lib/apparmor/profiles/*, /etc/apparmor.d/* and /etc/apparmor.d/abstractions/* to be earlier than before the mtime of the cache files would work. This works with device resets and works when the clock is moved forward.

I've discussed this with cwayne on irc and we'll come up with a solution for the custom tarball generation to account for this.

In the custom tarball generation, simply add something like:
touch -t 201312311159 /var/lib/apparmor/profiles/click_*

where '201312311159' is one minute before the mtime of the cache files.

I tested it with attached file in /etc/init and that fixed the issue.

@cwayne - did you put in place the workaround in #3 (or equivalent?)

Assigning to package that ships /etc/init/custom-apparmor-cache.conf. I'm not the owner of ubuntu-touch-customization-hooks so someone else needs to land it. That said, the approach seems reasonable and the script fine (though the double assignment for TIME_ROOTFS is not as clear as it could be). However, I question whether this should be a pre-start of custom-apparmor-cache.conf. On the one hand, we shouldn't need this at all but because we do for custom-apparmor-cache to work right so it makes sense, but on the other, perhaps this would be better placed in a more 'foundational/phondational' package. Can we get someone from Phonedations/Foundations to review and comment?

Yes, I'd put the workaround in place. I can try and get this landed in customizatoon-hooks as well if it's desired, but if the workaround is enough, we should be good for now

I'm all up to move it to more appropriate config, even to separate config,
rather than override, this was just place where I was testing it, to make
sure time is adjusted before we start validating custom apparmor caches.
I did not managed to get working TIME_ROOTFS formula in one go, that's the
reason for double assignment. I attached modified config without double
assignment.

On Fri, Nov 14, 2014 at 8:24 PM, Jamie Strandboge <email address hidden> wrote:

> Assigning to package that ships /etc/init/custom-apparmor-cache.conf.
> I'm not the owner of ubuntu-touch-customization-hooks so someone else
> needs to land it. That said, the approach seems reasonable and the
> script fine (though the double assignment for TIME_ROOTFS is not as
> clear as it could be). However, I question whether this should be a pre-
> start of custom-apparmor-cache.conf. On the one hand, we shouldn't need
> this at all but because we do for custom-apparmor-cache to work right so
> it makes sense, but on the other, perhaps this would be better placed in
> a more 'foundational/phondational' package. Can we get someone from
> Phonedations/Foundations to review and comment?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1385382
>
> Title:
> Clock set to past confuses AppArmor cache validation
>
> Status in AppArmor Linux application security framework:
> Won't Fix
> Status in “ubuntu-touch-customization-hooks” package in Ubuntu:
> Triaged
>
> Bug description:
> During initial boot sometimes clock could be set to past, which will
> confuse logic validating precompiled AppArmour cache, causing cache
> recreation.
> If time is not set correct(valid) value, even consequent boots will fail
> to validate cache, forcing cache recreation.
>
> This bug affects Initial out of the box experience, since device clock
> is set in the factory to default value, for example 0:0am 1st of
> January 2014
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/apparmor/+bug/1385382/+subscriptions
>

Conf file without double assignment.