interfaces: add fwupd interface #1688
Conversation
| # privileged access to the fwupd service. | ||
| # Usage: reserved | ||
|
|
||
| # DBus accesses |
There was a problem hiding this comment.
There seems to be one space of indentation here. Can you please remove it?
There was a problem hiding this comment.
Do you mean the two space before the "#", or the space between "#" and "DBus" ? Do we have format conventions on AppArmor rules?
There was a problem hiding this comment.
'#<2 spaces>privileged access to the fwupd service.' should be '#<one space>privileged access to the fwupd service.' is what Zygmunt meant. It doesn't mean anything to apparmor-- it is just the style we use.
|
I'm surprised there is no seccomp policy since that is needed for talking to dbus. Did you test this using |
|
|
||
| 1. Ensure your BIOS support UEFI firmware upgrading via UEFI capsule format | ||
| 2. Install the uefi-fw-tools snap from the store | ||
| 3. Ensure the 'fwupd' interface is connected |
There was a problem hiding this comment.
Please add necessary shell commands to connect the relevant slot/plug.
There was a problem hiding this comment.
Yes I did add the network and network-bind plug currently in the snap. Should we add those into the interface? Was thinking fwupd interface is not an implicit interface as the potential uefi-control interface we have in mind and we probably won't need dbus and its policy for uefi-control interface. But if thats need I could add it.
OK, I'll add the shell commands in the doc, the shell command is:
snap connect uefi-fw-tools:fwupdmgr uefi-fw-tools:fwupd
There was a problem hiding this comment.
IIRC, fwupd does fetch things from over the internet, so it will always need 'network'. However, it would be great if:
- you could remove all other plugs for fwupdmgr and list the needed syscalls here (and ideally a general idea why they are needed-- but don't waste time on that-- just a high level (eg, it "binds to a port", "it calls out over the network on launch", etc)). These calls may be added to PermanentSlotSecComp
- Now that the daemon has started, have the cli command talk to fwupdmgr and list those calls required for fwupdmgr to talk to the client. These would go in ConnectedSlotSecComp
- you could remove all other plugs from the cli command and talk to fwupdmgr and list those calls. These would go in ConnectedPlugSecComp.
There was a problem hiding this comment.
"IIRC, fwupd does fetch things from over the internet, so it will always need 'network'. However, it would be great if:
you could remove all other plugs for fwupdmgr and list the needed syscalls here (and ideally a general idea why they are needed-- but don't waste time on that-- just a high level (eg, it "binds to a port", "it calls out over the network on launch", etc)). These calls may be added to PermanentSlotSecComp
Now that the daemon has started, have the cli command talk to fwupdmgr and list those calls required for fwupdmgr to talk to the client. These would go in ConnectedSlotSecComp
you could remove all other plugs from the cli command and talk to fwupdmgr and list those calls. These would go in ConnectedPlugSecComp."
@timchen119, did you have a chance to look at this yet?
There was a problem hiding this comment.
I've remove all the plugs (network,network-bind) and added all the syscall needed in the code.
|
Marking as 'Blocked' until feedback is addressed. |
|
@timchen119 Do you have time to finalize the implementation with @jdstrand review comments? |
|
@morphis Thanks for all the review comments, was holiday until now. Will recommit this week. |
timchen119
force-pushed
the
fwupd-interface
branch
from
c9545a6
to
6754ad1
Compare
| owner @{PROC}/@{pid}/mounts r, | ||
| /sys/devices/pci*/**/block/**/partition r, | ||
| # The efivar library need ESP partition GUID,offset,size | ||
| #/dev/sd[a-z]* r, |
There was a problem hiding this comment.
Just curious, why is this commented out?
There was a problem hiding this comment.
/dev/sd[a-z]* r,
The upstream version of efivar lib need full disk access to get the partition guid and size info, I made a patch at timchen119/efivar@331e410 as a proof of concept to use udev runtime data to get these info, so we may change this in our snap to use this following rules without open the full disk access:
/run/udev/data/b* r,
Was seeking for a better suggestion instead of a modified efivars library as that would need more work to polish the patch and may break hw I don't have.
There was a problem hiding this comment.
Yes, please remove the /dev/sd[a-z]* r, and use this instead:
# Introspect the block devices to get partition guid and size information
/run/udev/data/b[0-9]*:[0-9]* r,
|
👍 (just one question about a commented out line in the apparmor code, if we don't need it, maybe we should just rmeove it? or add a comment why its commented out?). |
| # The efivar library need ESP partition GUID,offset,size | ||
| #/dev/sd[a-z]* r, | ||
| # Get data from udev with modified efivar library | ||
| /run/udev/data/b* r, |
There was a problem hiding this comment.
I see you added this already. Please use my slightly more fine-grained rule and update the comment for what you are looking for. Thanks!
|
Please adjust the comment and udev rule per my comment, and feel free to remove the unconfined dbus rule per my other comment, then +1. |
timchen119
force-pushed
the
fwupd-interface
branch
from
a1b3427
to
6fe265e
Compare
|
LGTM, @jdstrand any further comments? |
|
+1 |
timchen119
force-pushed
the
fwupd-interface
branch
from
6fe265e
to
754a28a
Compare
An interface that allows fwupd upgrading UEFI firmware via UEFI capsule format.