Add kernel lockdown setting

[tjkirch]

Issue number:

Adds the capability we'll need for #813.

Description of changes:

93f90b4a kernel: enable support for lockdown mode, disabled by default
f431a254 corndog: remove Result from set_sysctls to reflect that we don't let it fail
74e5cd21 Add a kernel lockdown setting and corndog helper
0b96d45a Add migrations necessary for kernel lockdown feature

This should cause no functional difference on the system since we default to 'none', but will allow users to set a lockdown level. Raising the lockdown level is probably safe for most use cases, but wouldn't work with some use cases described in #813, so we can't increase it by default at the moment.

Testing done:

Unit tests pass. Migrations work locally.

Created a 1.0.3 AMI without this change, and a repo including this change marked as version 1.0.5 (to match the migration list added to Release.toml). Updated from 1.0.3 to 1.0.5 successfully. Confirmed I could run a pod OK. Confirmed that the lockdown setting showed up in the API and the restart-commands list for sysctl was updated correctly by the migration. Further testing:

Default state:

bash-5.0# cat /sys/kernel/security/lockdown
[none] integrity confidentiality

Bad values are rejected:

bash-5.0# apiclient -u /settings -m PATCH -d '{"kernel": {"lockdown": "bad"}}'
Failed PATCH request to '/settings': Status 400 when PATCHing /settings: Json deserialize error: Unable to deserialize into Lockdown: Invalid Linux lockdown mode 'bad' at line 1 column 30

Good values accepted and applied:

bash-5.0# apiclient -u /settings -m PATCH -d '{"kernel": {"lockdown": "integrity"}}'
bash-5.0# apiclient -u /tx/commit_and_apply -m POST
["settings.kernel.lockdown"]
bash-5.0# cat /sys/kernel/security/lockdown
none [integrity] confidentiality

bash-5.0# apiclient -u /settings -m PATCH -d '{"kernel": {"lockdown": "confidentiality"}}'
bash-5.0# apiclient -u /tx/commit_and_apply -m POST
["settings.kernel.lockdown"]
bash-5.0# cat /sys/kernel/security/lockdown
none integrity [confidentiality]

Setting is still applied after reboot:

bash-5.0# reboot
...
[ec2-user@ip-192-168-16-84 ~]$ sudo sheltie
bash-5.0# cat /sys/kernel/security/lockdown
none integrity [confidentiality]

Applying the setting multiple times is handled safely in corndog (the kernel rejects the write):

bash-5.0# corndog lockdown
19:05:38 [INFO] Requested lockdown setting is already in effect.

Here's a manual run of corndog after changing the setting, and committing but not applying the changes, just to show it's happy:

bash-5.0# apiclient -u /settings -m PATCH -d '{"kernel": {"lockdown": "confidentiality"}}'
bash-5.0# apiclient -u /tx/commit -m POST
["settings.kernel.lockdown"]
bash-5.0# corndog lockdown
bash-5.0# corndog lockdown
19:07:30 [INFO] Requested lockdown setting is already in effect.

You can't downgrade at runtime...

bash-5.0# apiclient -u /settings -m PATCH -d '{"kernel": {"lockdown": "integrity"}}'
bash-5.0# apiclient -u /tx/commit_and_apply -m POST
["settings.kernel.lockdown"]
bash-5.0# corndog lockdown
19:13:51 [WARN] Can't lower lockdown setting at runtime; please reboot for it to take effect.

...but after a reboot, your request takes effect:

bash-5.0# cat /sys/kernel/security/lockdown
none [integrity] confidentiality

I confirmed that I could downgrade successfully to 1.0.3 and the lockdown setting was removed, and the restart-commands list was reverted.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[tjkirch]

^ This push adds a clarification to the README about needing to reboot after lowering the lockdown level.

[webern]

Nice upgrade/downgrade testing.

[tjkirch]

^ rebase on develop, in particular to fix a conflict in Release.toml where this and the 1.0.4 release both added an empty line for 1.0.3 -> 1.0.4 migrations.