Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

daemon: secureboot updates API endpoint #14541

Merged

Conversation

bboozzoo
Copy link
Contributor

Add a dedicated integration API endpoint for controlling/notifying of secure boot keys databases updates.

This is a draft PR with no unit tests, with the purpose of validating the API endpoint and the policy around it.

Related: SNAPDENG-32364 SNAPDENG-31856

@bboozzoo bboozzoo added the FDE Manager Pull requests that target FDE manager branch label Sep 26, 2024
@github-actions github-actions bot added the Needs Documentation -auto- Label automatically added which indicates the change needs documentation label Sep 26, 2024
Copy link
Collaborator

@pedronis pedronis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, looking reasonable, couple of comments

}

switch req.Action {
case "efi-secureboot-db-update":
Copy link
Collaborator

@pedronis pedronis Sep 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

having action and subaction is a bit unusual, also at least the startup action might be relevant to more types of fw updates than db-updates? can't we fold things into actions:

efi-secureboot-update-startup
efi-secureboot-update-db-prepare
efi-secureboot-update-db-cleanup?

is cleanup perhaps also relevant to other kind of updates?

Comment on lines 37 to 38
// TODO should this be only allowed for services with fwupd on slot
// side?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, as disussed we care about the slot side here, not the plug

var systemSecurebootCmd = &Command{
// TODO GET returning whether secure boot is relevant for the system?

Path: "/v2/system/secureboot",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looking at other end points it seems this might need to be /v2/system-secureboot ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering if there's a use case for exposing other properties of the system, eg disks (or storage), gadget, in which case those could be hosted at /v2/system/disks, and so on. wdyt?

@bboozzoo bboozzoo marked this pull request as ready for review October 1, 2024 14:06
Copy link
Collaborator

@pedronis pedronis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick about the JSON of the requests

func postSystemSecurebootActionJSON(c *Command, r *http.Request) Response {
var req struct {
Action string `json:"action,omitempty"`
Data *json.RawMessage `json:"data"`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would avoid having this nested "data" level, just define a top level struct with the field we need with a validate method that checks if field that should be set for a given op are or than't shouldn't aren't

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

Copy link
Collaborator

@pedronis pedronis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, small question

Comment on lines +174 to +177
// Slot when true, the snap must appear on the slot side
Slot bool
// Plug when true, the snap must appear on the plug side
Plug bool
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need to support setting both to true because the logic below and the descriptions here don't match in that case

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we have the use case for it then I think the we need a more complex structure that holds expectation for optional slot-side and plug-side interfaces for each combo we want to allow.

type interfaceAccessReq struct {
    PlugInterface string // If set then snap must have a connected plug for specified interface
    SlotInterface string // If set then snap must have a connected slot for specified interface
}

Then func requireInterfaceApiAccessImpl(d *Daemon, r *http.Request, ucred *ucrednet, req interfaceAccessReqs) *apiError would be func requireInterfaceApiAccessImpl(d *Daemon, r *http.Request, ucred *ucrednet, reqs []interfaceAccessReq) *apiError

This adds a lot of complexity, If we don't have the use case now then maybe better as a todo.

Copy link
Contributor

@ZeyadYasser ZeyadYasser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks really good, Thank you! I did a first pass

overlord/fdestate/fdestate.go Outdated Show resolved Hide resolved

// EFISecureBootDBUpdatePrepare notifies notifies that the local EFI key
// database manager is about to update the database.
func EFISecureBootDBUpdatePrepare(st *state.State, db EFISecurebooKeystDB, payload []byte) error {
Copy link
Contributor

@ZeyadYasser ZeyadYasser Oct 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid redoing work on the daemon side, Is there an agreement that those stubbed functions are expected to be there with similar signatures in the actual fdestate package?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, we don't have the feature yet, so this is best effort guess of what the API may look like

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then maybe @valentindavid can take a look if the function signatures make sense

Comment on lines +174 to +177
// Slot when true, the snap must appear on the slot side
Slot bool
// Plug when true, the snap must appear on the plug side
Plug bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we have the use case for it then I think the we need a more complex structure that holds expectation for optional slot-side and plug-side interfaces for each combo we want to allow.

type interfaceAccessReq struct {
    PlugInterface string // If set then snap must have a connected plug for specified interface
    SlotInterface string // If set then snap must have a connected slot for specified interface
}

Then func requireInterfaceApiAccessImpl(d *Daemon, r *http.Request, ucred *ucrednet, req interfaceAccessReqs) *apiError would be func requireInterfaceApiAccessImpl(d *Daemon, r *http.Request, ucred *ucrednet, reqs []interfaceAccessReq) *apiError

This adds a lot of complexity, If we don't have the use case now then maybe better as a todo.

daemon/access.go Show resolved Hide resolved
daemon/export_api_system_secureboot_test.go Show resolved Hide resolved
) (restore func()) {
restore = testutil.Backup(&fdestateEFISecureBootDBUpdateCleanup)
fdestateEFISecureBootDBUpdateCleanup = f
return restore
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above

daemon/export_api_system_secureboot_test.go Show resolved Hide resolved
Copy link
Contributor

@ZeyadYasser ZeyadYasser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

switch r.DB {
case "PK", "KEK", "DB", "DBX":
default:
return fmt.Errorf("invalid key DB %q", r.DB)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe error can include supported DBs?

return errNotImplemented
}

type EFISecurebootKeysDB int
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this could be named EFISecurebootKeysDatabase to avoid confusion with DB which is the name of the allowed signature key hashes database.

// DB is used with efi-secureboot-db-prepare action, and indicates the
// secureboot keys DB which is a target of the action, possible values are
// PK, KEK, DB, DBX
DB string `json:"db,omitempty"`
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similarly to the other comment in fdestate this could be named:

Suggested change
DB string `json:"db,omitempty"`
Database string `json:"database,omitempty"`

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@valentindavid pushed the changes we discussed, please have a look

… process being root

Add a new access checker which verifies that the request is coming from
a root user and if the process is a snap, a required interface is
connected, with that snap present on the slot side.

Signed-off-by: Maciej Borzecki <[email protected]>
…ureboot key DBs

Add a new endpoint for integration with a local manager of EFI
secureboot key databases.

Signed-off-by: Maciej Borzecki <[email protected]>
@pedronis pedronis merged commit 0a211fd into canonical:fde-manager-features Oct 7, 2024
41 of 52 checks passed
@bboozzoo bboozzoo deleted the bboozzoo/efi-secureboot-api branch October 7, 2024 09:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FDE Manager Pull requests that target FDE manager branch Needs Documentation -auto- Label automatically added which indicates the change needs documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants