Assertion system-user and the system time

snapd
,
1

(This has been filed as a bug, but following up here as there has been no activity on the bug).

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.

It has been pointed out that using “fixrtc” in the image will approximate the date/time to either the last mount time or creation time of the image. However, if the System-User Assertion is set to after that date/time, then valid assertions can be rejected. Also, since the user cannot log in to see the log, it is painful to work out why a System-User Assertion has been rejected.

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.

Thanks

James

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

1 Like
2

we haven’t forgotten about these issues, we even discussed them at some sprint, they are in the queue of things to look into after some other features are done

3

Okay, thanks. I was asked to post here to get some progress on the bug.

It would help if the bug was triaged and not left as “New”.

4

As i commented in the bug already, if you see a 1970 date anywhere on a non-x86 ubuntu core image, please file a bug against initramfs-tools.

While the date can be slightly off, a date matching the epoch on a system that has fixrtc enabled should not be possible at all and is a serious bug.

(indeed “slightly off” will still make you end up with invalid keys, but we want to know about any fixrtc bugs)

5

As @pedronis pointed out, we’ll look into this (the fact I’m coming back here being an evidence). Just wanted to add an extra note about this:

If there is a device owner, system-user assertions are not automatically accepted at all.

Then, more generically, if the owner has wide open access into the system, there’s of course no way to make the system safe from the owner itself.