Re: Privileged File Access from Desktop Applications

[Steffen Nurpmeso <steffen () sdaoden eu>]

Perry E. Metzger wrote in <20190711114710.09ab5ad9 () jabberwock cb.piermon\
t.com>:
 |On Thu, 11 Jul 2019 13:57:19 +0000 Malte Kraus <malte.kraus () suse com>
 |wrote:
 |> On Thu, 2019-07-11 at 09:33 -0400,  Perry E. Metzger wrote:
 ...
 |> I didn't (intend to) say there is an (additional) security problem.
 |> I just tried to succinctly explain why the desktop environments are
 |> coming up with these D-Bus interfaces now.
 |
 |It seems like a bad idea.
 |
 |If one wants to have mechanisms by which the operating system can
 |allow unprivileged programs to temporarily assume privileges (which
 |is a frequent idea in security), then they should be carefully
 |designed and part of the OS, rather than creating an ad hoc facility
 |via a subsystem that isn't intended for it. There are good ways to do
 |that, like capabilities.

Sending this remark because a few days ago i posted something
similar to a gnupg ML.

From my point of view there is root user hysteria in Unix and
clones, maybe forever, but i see it consciously in the last years.
If the solution against SETUID programs or other, finer grained
privileges, but which anyway can be detected via file system
tools, is that privilege adjustments u-boat away to something that
needs source code or over-the-wire analysis to being detected at
all, i fail to see how this leads to something better.

Without personally having made it there yet, i think the
traditional way of in-application sandboxing fits better, even
with SETUID programs which first perform some higher-privilege
setup before going more secure, like capsicum on FreeBSD,
pledge/unveil on OpenBSD, or prctl, seccomp (and apparmor) on
Linux.  Or even interesting entire frameworks like CloudABI.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)