System-User Assertions and the system time

[James Jesudason]

System-User assertions have a since/until timestamp on them to indicate their date range of their validity. This is checked against the current system date/time of the device [1]. From what I can see,for devices that do not have a real-time clock, the current date/time can be incorrect, especially if the network connection has not be configured (so the NTP server has not done its work).

In a factory, the newly provisioned devices may be tested without connecting it to a network, so devices like a Pi3 will typically have the wrong system date/time. A crude workaround is to set the "since" date of the assertion back a couple of days, but that won't work if a system defaults to a 1970 date.

Errors that I have seen are:
* "assertion not valid anymore"
* "assertion is signed with expired public key"

The first error happens because the system date is before the "since" date of the assertion. The second error is because the system defaulted to an even older date (5 days into the past), which was before the account-key assertion was created.

[1] https://github.com/snapcore/snapd/blob/6aaa6fa9d7a594cf164e8fcf40467afae4793017/daemon/api.go#L1957

[Oliver Grawert (ogra)]

systems defaulting to a 1970 date should not be possible if they are ported correctly.

using the (kind of mandatory) "fixrtc" commandline option on the kernel commandline. this will always set the system time to either last mount time or creation time of the image.

[James Jesudason (jamesj)]

Some observations that people have made:

* Why check a date range on the system-user assertion. If snapd just checked the expiry timestamp of the assertion, then that may be all that's needed - and it should work in most cases.

* An attempt to prevent use of signed messages based on the *local* clock is unreliable. In most cases, the device owner can directly manipulate the clock and, where they can't, they can
likely insert a spoofed ntp daemon on the network, unless we use an authenticated time source.

[James Jesudason (jamesj)]

The fixrtc solution feels like a bit of a workaround and not a solution. Even with the date/time set by fixrtc we've seen valid system-user assertions fail. The problem is that when a system-user assertion fails, you cannot login to the device to check the logs. From what I remember, it's a silent fail so you have no idea why the system-user is not created.

To me, the main issue is that validating a signed messaged on the local clock isn't secure or reliable.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

Including the patch from LP: #1696981 would be an improvement on the current fixrtc, as it looks into the date of some files in the system. I have found that some times the mount date is 1970 on first boot.

[Oliver Grawert (ogra)]

if fixrtc works the date can not be 1970 ... (it can surely be off by some margin but never be the epoch)

[Oliver Grawert (ogra)]

i know there was a discussion about simply dropping the date checks from assertion verification but i can not find it on https://forum.snapcraft.io now ...

[Zygmunt Krynicki (zyga)]

I'm moving this to the snapd project and triaging as high importance.