Allow plugins to request certain capabilities

[superm1]

Is your feature request related to a problem? Please describe.
Follow up to a discussion thread in #2460

Describe the solution you'd like
Currently all plugins (and the daemon) assume that they have full reign of the system. This means that any plugin could technically call any ioctl even if it didn't require it.

Not all plugins need this support, and the daemon should degrade it's capabilities in circumstances that plugins don't need them. This means things like dropping cap_sys_admin via PR_CAPBSET_DROP when no devices are detected needing specific capabilities at coldplug.

Additional context
We may choose not to have this enabled generally, but only in limited contexts such as a ChromeOS system. The reasoning is that if no NVME disks are present when the daemon starts up but a user plugs in an external NVME disk to a USB4 or Thunderbolt3 enclosure but the daemon already dropped capabilities, it can't be interacted with anymore.

[hughsie]

Plugins need to then have a handshake to indicate what they actually need that means.

I guess there are two ways to do this:

• Plugins call fu_plugin_require_caps(p, "cap_sys_admin") and then the engine drops all the caps except the ones requested by the plugins -- which means that on specific chrome systems they'd be a model-specific fwupd.conf.d that disables a specific plugin.

or..

• Plugins call fu_plugin_require_caps(p, "cap_sys_admin") and then if the daemon isn't running with that capability then the plugin gets disabled automatically rather than failing when trying to write to the firmware. Maybe this isn't so required; perhaps the _setup() will fail without caps and then the plugin will self-disable...

[superm1]

I guess to figure out how much to engineer this solution are we just talking about cap_sys_admin? Or are there others that should be dropped too?

If it's cap_sys_admin only then I think the only affected plugin is nvme or ata. Letting another process control it seems fine in that context.

[hughsie]

are we just talking about cap_sys_admin

That's a very good point, I suppose we are. @djcampello would know if there's anything else.

[superm1]

Looking at the file linked in the other PR: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/master/sys-apps/fwupd/files/fwupdtool-update.conf#23

It's also cap_dac_override and they control some extra groups that get access to data. I'm still leaning on letting that be an external thing to fwupd though as it's specifically for the purpose of the nvme plugin that cap_dac_override was used too.

[superm1]

Another idea popped into my head specific to the ChromeOS use case. The whole reason for wanting to have plugin separation is so that you don't get a process with all the permissions all the time.

The metadata is "fixed" on ChromeOS, so why not just offer a mode that drops permissions for all plugins for devices without updates? So you'll get a process that launches with cap_sys_admin, cap_dac_admin and when no NVME/ATA/MMC updates are available those capabilities get evicted.

[hughsie]

and when no NVME/ATA/MMC updates are available those capabilities get evicted

In Mondays call we talked about supporting the case where people plug random hardware in at runtime rather than having it connected at boot time. Although, I think hotplugging an NVMe disk or even ATA disk seems unlikely on a chromebook.

In all honesty I think we're scrabbling around for a solution when we don't really understand the problem; what exact issue are we trying to fix? If it is "fwupd should run without cap_sys_admin if the platform doesn't support nvme hardware" then what does dropping the capability make more safe? Is the libxmlb parsing seen as a weakness? or the gcab parsing? Is malicious file a realistic worry when the metadata is pre-cooked and sanitised per device? If it's malicious device, e.g. a FPGA attached to the PCI bus then that's a different solution too.