oss-sec mailing list archives
Re: major changes if gnu/linux dominates the desktop and/or mobile market?
From: Simon McVittie <smcv () debian org>
Date: Tue, 6 Oct 2020 16:17:06 +0100
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
Current thread:
- Re: major changes if gnu/linux dominates the desktop and/or mobile market?, (continued)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Greg KH (Oct 05)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Ian Zimmerman (Oct 05)
- Re: Re: major changes if gnu/linux dominates the desktop and/or mobile market? Stephen John Smoogen (Oct 05)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Georgi Guninski (Oct 06)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Georgi Guninski (Oct 07)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Ian Zimmerman (Oct 05)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Greg KH (Oct 05)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Steve Grubb (Oct 05)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Simon McVittie (Oct 06)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Steve Grubb (Oct 06)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Solar Designer (Oct 19)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Ian Zimmerman (Oct 19)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Simon McVittie (Oct 19)
- Re: major changes if gnu/linux dominates the desktop and/or mobile market? Simon McVittie (Oct 06)