On 25/02/16 17:18, daniel curtis wrote:
> Anyway, there is a one thing which wonders me:
> '/var/lib/dbus/machine-id'. According to the DENIED messages in a log
> files, there is something like this:
>
> name="/var/lib/dbus/machine-id", denied mask 'r'
The systemd machine ID (always /etc/machine-id) and the older D-Bus
machine ID (traditionally /var/lib/dbus/machine-id) are both a
randomly-generated unique ID (UUID, GUID) for the machine, intended to
be used in the situations where a hostname would traditionally be used.
Because hostnames are user-facing and partially cosmetic, they could get
changed by deliberate reconfiguration or a misconfigured DHCP client;
and because they are user-facing and short, they are non-unique (for
example consider how many machines have hostnames like "ubuntu" or
"localhost"). The machine ID is intended to avoid both of those issues.
Anything that needs a unique identifier for the machine, and does not
need to be prevented from identifying the machine for privacy reasons,
should read /etc/machine-id, its compile-time-configured
${localstatedir}/dbus/machine-id, and /var/lib/dbus/machine-id (ideally
in that order). It isn't *only* for D-Bus. The designers of D-Bus
introduced it partially because a couple of D-Bus features needed it,
and partially as a general "API" for the rest of the system.
For example, gnome-settings-daemon stores multi-display configurations
keyed by machine ID, so that you can share an NFS home directory between
machine A (where the HDMI monitor is to the left of the VGA monitor) and
machine B (where the HDMI monitor is above the laptop display), and each
machine gets its correct monitor configuration.
When connecting to the session bus, D-Bus implementations might need the
machine ID as part of the X11 autolaunch and DBUS_COOKIE_SHA1 protocols,
but X11 autolaunch is a bad idea (set DBUS_SESSION_BUS_ADDRESS correctly
instead) and DBUS_COOKIE_SHA1 should never be necessary on Linux (the
session bus now defaults to only allowing the simpler and more secure
EXTERNAL authentication). A modern Linux system shouldn't need it for
either of those features.
Connecting to the system bus doesn't require the machine ID at all, if I
remember correctly.
> "Some programs may request access to the DBus system bus socket, but may
> not actually need it for normal functioning. In these cases, (...) the
> same may be the case for the dbus machine-id:
>
> deny /var/lib/dbus/machine-id r,"
I don't think that's specifically saying that you should allow reading
the machine ID, or that you should deny reading the machine ID.
Similarly, it is not saying that you should allow or deny connecting to
the system bus socket (see <abstractions/dbus-strict> for what that
means) or the session bus socket (<abstractions/dbus-session-strict>).
What it is saying is that neither is necessarily always correct, and
you'll need to make your own decision, based on an assessment of what
the program does, what its fallback behaviour would be for denial, and
your own security policy (i.e. how much functionality you would be
willing to give up for increased privacy).
There are various possible reasons why plugin-container might read the
machine ID; I don't know which one applies.
In practice, if plugin-container is able to determine IP addresses,
network device MAC addresses, hardware serial numbers, the username, the
fully-qualified hostname and other identifying information, then there
is little point in preventing it from reading the machine ID, because it
probably already has enough information to identify a machine uniquely.
If it is sufficiently locked-down to have only a small subset of that
information, then there might be some benefit in preventing it from
reading the machine ID as well.
Regards,
a D-Bus maintainer
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
