With grade dangerous we don't want to install the datasource restriction file,
so only install it if we installed files and if we are filtering those files.
In the case where we are filtering files but there are no files to install, we
will already not create the file, but if we are filtering and we try to install
some files but they all get filtered out, then we will not install a datasource
restriction file because nothing untrusted from ubuntu-seed was installed, only
files from the gadget which are never filtered but are trusted.
Also remove a redundant test case now that it is reflected in the bigger test
case table.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Cloud-init itself only considers .cfg files in the cloud-init.cfg.d directory,
so we should only consider files with .cfg file extension in the ubuntu-seed
directory.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
This function is the directory analogue of cloudDatasourcesInUse, and takes
into account the fact that a collection of config files coming from the same
dir will be processed by cloud-init "together" with lexically later files
overwriting settings of lexically earlier files.
This is necessary for full MAAS support with cloud-init on grade signed
systems.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
For the error case we should only concern ourselves with checking if the output
is "status: error", anything else should not be handled with the switch case,
as that could obscure the non-zero exit status with returning an otherwise
valid status. In other words, if cloud-init status returns "status: enabled"
but exits with non-zero exit code, we still want to return CloudInitErrored.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
When cloud-init is actually in error condition, it will exit with a non-zero
status code. We previously had been assuming that this condition would have a
zero exit code, so the code would end up returning a non-nil err which in
devicestate would lead to devicestate never attempting to restrict cloud-init
and never disabling it either, thus effectively leaving the entire machinery
around force disabling cloud-init after 3 minutes if it was in error never to
be executed.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
This will filter out the config we allow on ubuntu-seed to a subset of
cloud-init configuration.
Currently, this just allows configuration as required by MAAS to setup a device
with cloud-init, but this could be expanded in the future.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
We previously would just create a list with the duplicated names in it, which
didn't break anything but may be confusing for some other bits of code later
on. Instead trim out duplicates using a map instead of appending directly into
the resultant list.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
In a future commit, we will use the result of measuring the datasource settings
for the cloud-init config from the gadget, but for now just introduce the
machinery to read it.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Move more responsibility of handling cloud-init config permission handling to
sysconfig instead of devicestate since we now have access to the model in
ConfigureTargetSystem which we can use to get the model grade.
This also means we can refactor the functions which install cloud-init config
to be more straight forward and readable.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Also fix an out-dated comment in installCloudInitCfgDir which referenced a
non-existent function.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Do nothing when cloud-init is not present, and cannot be run. Snapd will no
longer spam the logs with failed attempts to query cloud-init status
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Without this key in the cloud-init restrict file, cloud-init on subsequent boots
will not know what instance-id to trust, as in multipass and other NoCloud
deployments the instance-id will only be available via the NoCloud CIDATA
filesystem label, but the snapd restriction file will not allow reading or
importing that filesystem label and so cloud-init will not know whether it is in
a new first boot like in the cloud where a "golden image" is booted with a given
cloud-init and then saved and rebooted with a new instance-id.
When cloud-init is unable to detect the instance-id of the current boot, it
assumes that it is booting a "golden image" and will search for new
configuration input and thus a new instance-id, but in the case of multipass,
where all cloud-init configuration is provided via NoCloud CIDATA filesystem
label drives, subsequent boots will "undo" the initial networking configuration
because cloud-init does not trust it's cached data and as such will do the
default configuration which overwrites the previous boot's cloud-init specified
configuration.
This additional key instructs cloud-init to trust it's cache of the instance-id,
thus not overwriting previous configuration.
Fixes: https://bugs.launchpad.net/snapd/+bug/1905983
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* tests: update spread tests for cloud-init restrict file's "manual_cache_clean"
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* sysconfig,tests/cloud-init: don't add manual_cache_clean for "real" clouds
For real clouds, the instance-id will still be readable even after we have
restricted the datasource, so we don't need to set manual_cache_clean for those.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* sysconfig/cloudinit.go: add bug + doc links to comment on nocloudRestrictYaml
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Also include "None" datasource in the definition of a local datasource on UC20
so it is disabled after first boot even when used.
We don't change the behavior on UC16/UC18 however, so on those platforms the
"None" datasource will just be restricted to only ever allow cloud-init to use
"None" as a datasource, so users of the "None" datasource with cloud-init on
Ubuntu Core will still be protected from the specific NoCloud attack from
CVE-2020-11933.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
