[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190711211400.GB24270@espresso.pseudorandom.co.uk>
Date: Thu, 11 Jul 2019 22:14:00 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: Privileged File Access from Desktop Applications
On Thu, 11 Jul 2019 at 17:31:38 +0100, John Haxby wrote:
> Obviously one could split the process into its graphical half and its
> messing-around-with-disks half
This is not a new idea: one could, and some have. udisksd includes
approximately the messing-around-with-disks half of gparted, and GNOME
Disks (formerly palimpsest) is one example of the graphical half. I'm
sure there are other UIs that use udisksd, such as a KDE equivalent of
GNOME Disks, but I don't know their names. Their functionality is not
identical (GNOME Disks and udisksd also cover other disk operations such
as mounting and SMART checks, and I'm not sure whether they implement
all the same corner cases of partitioning that parted does) but there
is a lot of overlap.
If there are useful things that can be expressed by parted APIs but
not by udisks APIs, I would suggest opening feature requests with the
udisks project.
As an example of how established this pattern is, the hal (Hardware
Abstraction Layer) service was available in Debian stable releases
from 2005 onwards. hal was later replaced by multiple domain-specific
services like udisks, because other aspects of its design turned out
to be inefficient and it had the "jack of all trades, master of none"
problem, but the general concept of unprivileged UIs sending requests
to a system service has continued.
> but it's not clear to me how the graphical
> half would handle authentication[*] for the process that needs to run
> as root
The part that runs as root is usually a system service that is made
available as part of the OS and runs as root to begin with, either during
boot or on-demand, often by an init system like systemd, sysvinit or
Upstart or by the D-Bus system message bus' "activation" mechanism.
It typically receives IPC messages via an AF_UNIX socket (or D-Bus,
which is basically a higher-level layer around AF_UNIX), and can inspect
the credentials of its client in a race-free way via OS-specific kernel
APIs like Linux SO_PEERCRED, which cannot be faked by a malicious client.
In particular, udisksd (see above) and polkitd (see below) are both
system services designed to be launched by the OS in this way.
> There are any number of administrative tasks that will need
> to be redesigned to cope with this change.
Again, this is not new. Many administrative tasks can already be done via
system services that are addressable via IPC, often via D-Bus and with
authorization carried out by polkit (formerly PolicyKit) according to a
security policy codified by upstream defaults, distribution configuration
by a vendor or local configuration by a sysadmin. In particular, more
or less everything with a system-wide effect that is provided by GNOME's
Settings app (internally named gnome-control-center), or its equivalents
in other desktops, already works like this.
D-Bus is not the only suitable IPC mechanism (although it is a convenient
and popular one, and the one I'm most familiar with) and polkit is
not the only way to codify policy - some services offer their own IPC
protocols over an AF_UNIX socket, and have their own configuration to
determine who can do what using those protocols.
smcv
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
