OS-level privilege separation work

Anton Kachalov rnouse at google.com
Tue Apr 6 01:48:23 AEST 2021


Follow-up after last week's Security Working group meeting.

The idea is that changes' reviews might be slowed down because the
changes don't have instant impact and can not be tested "here and
now".

A while ago there was a discussion in Discord:

https://discord.com/channels/775381525260664832/775694761775464468/803832183260184576

> Brad Bishop:
> A couple reasons I had for putting the systemd units and udev rules in the application repositories were:
> 1 - I looked at a couple other ubiquitous projects and that is what they were doing
> 2 - putting them in bitbake makes it easy for everyone to do one-off hacks in their specific machine layer, so was trying to discourage that a bit.

That encourages to move systemd unit files & other configs (e.g.
busconfig ACLs) into individual repos whenever possible.

We have to modify individual repos three times:
1. Refactor openbmc meta & individual repo to move configs as per
above suggestion.
2. Change service one by one to run services as non-root that implies
intermediate busconfig ACLs change to include both: root and non-root
ACLs.
3. Once we have all applicable services run as non-root, drop
root-related ACLs from the configs.

First step affects both openbmc meta and individual repo. The change
will be complex because of refactoring and introducing new features at
the same time. Changes to individual repo, once merged, will block
other changes for this repo until openbmc's meta-related change is
merged due to incompatibility between individual repo head and current
openbmc meta.

To reduce complexity and speedup review process for the busconfig ACLs
introduction I would like to suggest to proceed with one bigger change
to openbmc meta that doesn't refactor how configs are being supplied,
keeping the changes to several services in top-level meta simple &
similar, easy to review. This approach also will have instant impact:
once merged we will have enforced ACLs for D-Bus.

Roughly the change will looks like this (it's a bit outdated):

   https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/37844

The final change would exclude refactoring for systemd to make changes
scoped & simplified. I've checked those changes on a number of targets
that can be run under QEMU.

Beforehand we have to review the following changes:

 - certificate-manager:
   https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/41430
   https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-certificate-manager/+/41166/
   https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-user-manager/+/41429

 - phosphor-logging:
   https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-logging/+/41835
   https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/41834

 - phosphor-hwmon:
   https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-hwmon/+/40277
   https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-hwmon/+/40214
   https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/40359

To move towards OS-level privilege separation we need to review this
blocking changes:

   https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/36965
   https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/41432
   https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/41471


More information about the openbmc mailing list