[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 Oct 2020 16:17:06 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: major changes if gnu/linux dominates the desktop
and/or mobile market?
On Mon, 05 Oct 2020 at 22:36:14 -0400, Steve Grubb wrote:
> I will skip the whole discussion on access control. However to prove security
> requires going through a Common Criteria certification. The biggest issue is
> that the desktoptop uses dbus instantiation which does not have the auid of
> the requesting process. Meaning audit cannot work.
>
> The fix was kdus. That was rejected. But the issue remains. There cannot be a
> secure desktop without auditing.
That depends on your threat model. If the attack you are defending against
is local user Alice being attacked by malicious privileged local user Bob,
then, yes, knowing which processes belong to Bob is necessary.
However, if the attack you are defending against is Alice's email client
being attacked by a malicious or compromised game that is also running
as Alice, then auids (and uids in general) are not interesting. This is
the security boundary that Flatpak, Snap, Firejail are trying to put up.
With dbus maintainer hat on, if there are facts that I can know about
the (AF_UNIX socket belonging to the) requesting process in a way that
does not involve race conditions, I'm happy to review patches to plumb
them through D-Bus and make them available to other processes. This
would have to look a lot like the recent addition of SO_PEERGROUPS
(D-Bus representation: UnixGroupIDs) and less recently, SO_PEERSEC
(LinuxSecurityLabel), so the prerequisite is the Linux kernel adding new
SO_PEERTHING options that give the necessary information (or a *BSD, etc.
kernel providing an analogous interface).
If audit is important to you, a new SO_PEERAUDIT that looks like
SO_PEERCRED but carries a struct { session ID, loginuid } would make sense?
As far as I'm aware, reading /proc is not suitable for this purpose,
because the dbus-daemon retrieving this information for a particular pid
can race with the process exiting and its pid being reused. If there was
a SO_PEERPIDFD that provided race-free access to a pidfd for the initiator
of the connection, that would maybe work? (As long as there's no mechanism
by which a process can exec a setuid or otherwise privileged binary that
can reset its audit session ID and/or loginuid.)
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.
