oss-sec mailing list archives
Re: Privileged File Access from Desktop Applications
From: Simon McVittie <smcv () debian org>
Date: Thu, 11 Jul 2019 22:14:00 +0100
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
Current thread:
- Privileged File Access from Desktop Applications Malte Kraus (Jul 09)
- Re: Privileged File Access from Desktop Applications Perry E. Metzger (Jul 09)
- Re: Privileged File Access from Desktop Applications Perry E. Metzger (Jul 10)
- Re: Privileged File Access from Desktop Applications Malte Kraus (Jul 11)
- Re: Privileged File Access from Desktop Applications Perry E. Metzger (Jul 11)
- Re: Privileged File Access from Desktop Applications Matthias Gerstner (Jul 11)
- Re: Privileged File Access from Desktop Applications Malte Kraus (Jul 11)
- Re: Privileged File Access from Desktop Applications Perry E. Metzger (Jul 11)
- Re: Privileged File Access from Desktop Applications Bob Friesenhahn (Jul 11)
- Re: Privileged File Access from Desktop Applications John Haxby (Jul 11)
- Re: Privileged File Access from Desktop Applications Simon McVittie (Jul 11)
- Re: Privileged File Access from Desktop Applications Simon McVittie (Jul 11)
- Re: Privileged File Access from Desktop Applications Perry E. Metzger (Jul 11)
- Re: Privileged File Access from Desktop Applications Jordan Glover (Jul 12)
- Re: Privileged File Access from Desktop Applications Perry E. Metzger (Jul 12)
- Re: Privileged File Access from Desktop Applications Perry E. Metzger (Jul 12)
- Re: Privileged File Access from Desktop Applications Steffen Nurpmeso (Jul 12)
- Re: Privileged File Access from Desktop Applications Perry E. Metzger (Jul 09)
- Re: Privileged File Access from Desktop Applications Steffen Nurpmeso (Jul 11)
- Re: Privileged File Access from Desktop Applications Simon McVittie (Jul 11)