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.