acpi-tools does not have sufficient access rights (acpidump)

[Geoffroy Van Cutsem]

The acpi-tools snap has the 'hardware-observe' interface, but this is not (no longer?) sufficient for 'acpidump' to run correctly.

This is error thrown (Ubuntu 20.04 base installion):
$ sudo acpi-tools.acpidump -b
Cannot open directory - /sys/firmware/acpi/tables
Could not get ACPI tables, AE_ACCESS

Note that it's possible to run this if the snap was installed with the '--devmode' flag.

[Ian Johnson (anonymouse67)]

Hi, can you paste the system journal denials for this snap:

journalctl --no-pager | grep DENIED | grep acpi-tools

Thanks

[Geoffroy Van Cutsem (gvancuts)]

Here you go:

$ journalctl --no-pager | grep DENIED | grep acpi-tools
Jan 17 12:18:17 acrn-vecow audit[5468]: AVC apparmor="DENIED" operation="open" profile="snap.acpi-tools.acpidump" name="/sys/firmware/acpi/tables/" pid=5468 comm="acpidump" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 17 12:18:17 acrn-vecow kernel: audit: type=1400 audit(1642418297.370:87): apparmor="DENIED" operation="open" profile="snap.acpi-tools.acpidump" name="/sys/firmware/acpi/tables/" pid=5468 comm="acpidump" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 17 12:18:28 acrn-vecow audit[5493]: AVC apparmor="DENIED" operation="open" profile="snap.acpi-tools.acpidump" name="/sys/firmware/acpi/tables/" pid=5493 comm="acpidump" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Jan 17 12:18:28 acrn-vecow kernel: audit: type=1400 audit(1642418308.098:88): apparmor="DENIED" operation="open" profile="snap.acpi-tools.acpidump" name="/sys/firmware/acpi/tables/" pid=5493 comm="acpidump" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Jan 17 12:18:33 acrn-vecow audit[5518]: AVC apparmor="DENIED" operation="open" profile="snap.acpi-tools.acpidump" name="/sys/firmware/acpi/tables/" pid=5518 comm="acpidump" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 17 12:18:33 acrn-vecow kernel: audit: type=1400 audit(1642418313.462:89): apparmor="DENIED" operation="open" profile="snap.acpi-tools.acpidump" name="/sys/firmware/acpi/tables/" pid=5518 comm="acpidump" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 17 12:18:41 acrn-vecow audit[5551]: AVC apparmor="DENIED" operation="open" profile="snap.acpi-tools.acpidump" name="/sys/firmware/acpi/tables/" pid=5551 comm="acpidump" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 17 12:18:41 acrn-vecow kernel: audit: type=1400 audit(1642418321.510:90): apparmor="DENIED" operation="open" profile="snap.acpi-tools.acpidump" name="/sys/firmware/acpi/tables/" pid=5551 comm="acpidump" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 17 12:20:15 acrn-vecow audit[5724]: AVC apparmor="DENIED" operation="open" profile="snap.acpi-tools.acpidump" name="/sys/firmware/acpi/tables/" pid=5724 comm="acpidump" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Jan 17 12:20:15 acrn-vecow kernel: audit: type=1400 audit(1642418415.884:91): apparmor="DENIED" operation="open" profile="snap.acpi-tools.acpidump" name="/sys/firmware/acpi/tables/" pid=5724 comm="acpidump" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Jan 17 12:45:27 acrn-vecow audit[13798]: AVC apparmor="DENIED" operation="open" profile="snap.acpi-tools.acpidump" name="/sys/firmware/acpi/tables/" pid=13798 comm="acpidump" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 17 12:45:27 acrn-vecow kernel: audit: type=1400 audit(1642419927.523:92): apparmor="DENIED" operation="open" profile="snap.acpi-tools.acpidump" name="/sys/firmware/acpi/tables/" pid=13798 comm="acpidump" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

[Colin Ian King (colin-king)]

being able to have read access on the firmware tables from /sys/firmware/acpi/tables with root access is kinda pivotal in being able to run this tool.

[Ian Johnson (anonymouse67)]

Hmm, I'm confused since the denials you're seeing should be allowed by the policy generated when hardware-observe is connected, see this line:

https://github.com/snapcore/snapd/blob/1126fd32a9b0c9c6d1f5da58193c69675f0a57fd/interfaces/builtin/hardware_observe.go#L51-L52

What's the output of:

snap version
snap connections acpi-tools
snap changes acpi-tools

[Geoffroy Van Cutsem (gvancuts)]

That's what I was thinking initially too, and this is when I asked Colin whether the snap had the hardware-observe interface, which it does.

Is there a problem with the level of recursiveness needed to get to the information? What struck me in that hardare_observe.go file too is that you have specific entries listed that should be covered by the lines you pointed out. Here are a couple of such entries:
- DMI tables: https://github.com/snapcore/snapd/blob/1126fd32a9b0c9c6d1f5da58193c69675f0a57fd/interfaces/builtin/hardware_observe.go#L57-L59
- Memory configuration: https://github.com/snapcore/snapd/blob/1126fd32a9b0c9c6d1f5da58193c69675f0a57fd/interfaces/builtin/hardware_observe.go#L81-L85
Why do you need those in addition to the much broader read access granted in lines 51 & 52?

Here is the ouptut you requested:
$ snap connections acpi-tools
Interface Plug Slot Notes
hardware-observe acpi-tools:hardware-observe - -
home acpi-tools:home :home -

$ snap version
snap 2.53.4
snapd 2.53.4
series 16
ubuntu 20.04
kernel 5.11.0-46-generic

$ snap changes acpi-tools
no changes found

[Maciej Borzecki (maciek-borzecki)]

@gvancuts most likely a bug, looking at git blame, the DMI entries were added in July 2016, while the boarder entry you pointed to was added in August 2016. Most likely nobody noticed there was an overlap between the new entry some of the existing ones.

[Geoffroy Van Cutsem (gvancuts)]

@maciek-borzecki what about these: https://github.com/snapcore/snapd/blob/1126fd32a9b0c9c6d1f5da58193c69675f0a57fd/interfaces/builtin/hardware_observe.go#L81-L85

These were added in May 2018 when the generic access to /sys/{block,bus,class,devices,firmware} was already in place. Could it be that this was not needed but added nevertheless?

The git commit message (https://github.com/snapcore/snapd/commit/11e4288bff87ef713cf80200fdb7351dea59829c) does not say anything specific about it (neither does the PR conversations show anything about this: https://github.com/snapcore/snapd/pull/5189). Perhaps @jdstrand remembers?

[Maciej Borzecki (maciek-borzecki)]

I believe it's the same story. In addition to the lines allowing access to memory info, I also dropped https://github.com/snapcore/snapd/blob/1126fd32a9b0c9c6d1f5da58193c69675f0a57fd/interfaces/builtin/hardware_observe.go#L142-L143 and verified that lsmem and systemd-detect-virt worked as expected. Though I'm bit undecided whether we should drop those lines, in case the rule giving a broad access is tweaked at some point and made more specific, thus break programs accessing the other explicitly listed locations which would be gone now.

[Geoffroy Van Cutsem (gvancuts)]

I can see your point, I think I'd do the same, i.e. keep those lines as they do not do any harm and make it explicit what is needed for what.

I just do not understand why acpidump does not work...

[Maciej Borzecki (maciek-borzecki)]

The hardware-observe interface isn't auto-connected, so one has to run `snap connect acpi-tools:hardware-observe` or the publisher can request auto connection from the store in the forum.

[Colin Ian King (colin-king)]

OK - I'll ask for that permission. Is this "ask for auto connection" policy documented?

[Colin Ian King (colin-king)]

https://forum.snapcraft.io/t/hardware-observe-auto-connect-request-for-acpi-tools/28380

[Geoffroy Van Cutsem (gvancuts)]

I see, thanks for the hint. It does work correctly after I connect the interface.

I'm not familiar with this auto-connection thing, but why does it have to be done manually?

It would also make sense from a user experience perspective to throw a message in that sense so the user gets a hint as to how it can solve this error.

[Geoffroy Van Cutsem (gvancuts)]

Will this not get in the way of the request for an auto-connection? https://github.com/snapcore/snapd/blob/master/interfaces/builtin/hardware_observe.go#L29

[Maciej Borzecki (maciek-borzecki)]

The catch is that hardware-observe allows accessing some potentially sensitive information about the host system, hence auto-connect is denied by default (as seen in the source code). The details of this mechanism are described here: https://snapcraft.io/docs/auto-connection-mechanism The user can still do the connection manually. From within the snap you can check whether the given plug is connected by calling `snapctl is-connected hardware-observe` as described in: https://snapcraft.io/docs/using-snapctl I know that some snaps do that and issue a warning when the plug they checked for is disconnected.

The auto-connect can be overridden centrally through a snap declaration issued by the store. That is, you can ask in the snapcraft forum for the auto connection to be done automatically, you need to state the reason and have to be a verified publisher (IOW there needs to be some level of trust).

[Colin Ian King (colin-king)]

The hardware observe is quite broad in what it allows access to. Perhaps read-only access to ACPI tables should be in a plugin of it's own to provide some more fine grained access control. Also, what is the security risk from being able to have read-only access to ACPI tables?

There are other tools such as the de-factro ACPI test tool "fwts" (Firmware Test Suite) that could also use this kind of ACPI table access plugin.

[Launchpad Janitor (janitor)]

[Expired for snapd because there has been no activity for 60 days.]