Re: [GIT PULL] kdbus for 4.1-rc1

[Simon McVittie]

On 29/04/15 14:35, Stephen Smalley wrote:
> As it currently stands, there
> are no LSM hook calls in the kdbus tree beyond metadata collection of
> security labels.

SELinux and AppArmor are the two particularly interesting LSMs here:
those are the ones that have support for user-space mediation in
dbus-daemon, and hence the ones for which replacing dbus-daemon with
kdbus, without LSM hooks, would be a regression.

> It is also interesting that kdbus allows impersonation of any
> credential, including security label, by "privileged" clients, where
> privileged simply means it either has CAP_IPC_OWNER or owns (euid
> matches uid) the bus.

FWIW, this particular feature is *not* one of those that are necessary
for feature parity with dbus-daemon. There's no API for making
dbus-daemon fake its clients' credentials; if you can ptrace it, then
you can of course subvert it arbitrarily, but nothing less hackish than
that is currently offered.

> On 04/29/2015 08:47 AM, Harald Hoyer wrote:
>>  * Eavesdropping on the kernel level, so privileged users can hook into
>>the message stream without hacking support for that into their
>>userspace processes
> 
> This one worried me a bit, particularly the statement that such
> eavesdropping is unobservable by any other participant on the bus.
> Seems a bit prone to abuse, particularly since it can be done by any
> privileged client, not merely the process that originally created the bus?

For feature parity with dbus-daemon, the fact that
eavesdropping/monitoring *exists* is necessary (it's a widely used
developer/sysadmin feature) but the precise mechanics of how you get it
are not necessarily set in stone. In particular, if you think kdbus'
definition of "are you privileged?" may be too broad, that seems a valid
question to be asking.

In traditional D-Bus, individual users can normally eavesdrop/monitor on
their own session buses (which are not a security boundary, unless
specially reconfigured), and this is a useful property; on non-LSM
systems without special configuration, each user should ideally be able
to monitor their own kdbus user bus, too.

The system bus *is* a security boundary, and administrative privileges
should be required to eavesdrop on it. At a high level, someone with
"full root privileges" should be able to eavesdrop, and ordinary users
should not; there are various possible criteria for distinguishing
between those two extremes, and I have no opinion on whether
CAP_IPC_OWNER is the most appropriate cutoff point.

In dbus-daemon, LSMs with integration code in dbus-daemon have the
opportunity to mediate eavesdropping specially. SELinux does not
currently do this (as far as I can see), but AppArmor does, so
AppArmor-confined processes are not normally allowed to eavesdrop on the
session bus (even though the same user's unconfined processes may). That
seems like one of the obvious places for an LSM hook in kdbus.

Having eavesdropping be unobservable means that applications cannot
change their behaviour while they are being watched, either maliciously
(to hide from investigation) or accidentally (bugs that only happen when
not being debugged are the hardest to fix). dbus-daemon's traditional
implementation of eavesdropping has had side-effects in the past, which
is undesirable, and is addressed by the new monitoring interface in
version 1.9. kdbus' version of eavesdropping is quite similar to the new
monitoring interface.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
For context, I am a D-Bus maintainer, but neither the original designer
of D-Bus nor a kdbus developer.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Early comments on kdbus v2 (Re: [PATCH 00/12] Add kdbus implementation)

[Simon McVittie]

On 05/11/14 15:56, Andy Lutomirski wrote:
>  - I tend to think that pid and tid should be separate.  They're
> really their own thing, and, as noted in all the perfectly valid
> dislike directed at SO_PEERCRED, they have extremely limited value.

Traditional D-Bus has GetConnectionUnixProcessID(), which is used by
several applications:
,
 (the latter is the Qt
binding).

I don't know what those applications use it for, or whether they're
doing it safely. CVE-2013-4288, CVE-2014-5033 seem potentially relevant.

In the same way that kernel people don't want to break userland, I don't
want to break existing D-Bus users; it would be a shame if kdbus omits
things that would let it replace traditional D-Bus.

>  - starttime should have a justification or be removed.

I think its justification is "detect pid reuse", although AIUI it
doesn't detect pid "reuse" via exec().

>  - KDBUS_ATTACH_AUXGROUPS: I'm not sure what to think about this.  I
> feel like it's only useful for implementing strange types of policies.

I think the intention is that it enables things like "processes with
group netdev may tell NetworkManager to reconfigure networking".
Traditional D-Bus half-supports this, but interacts poorly with things
like pam_groups that assign groups to processes, not uids.

>  - KDBUS_ATTACH_SECLABEL: The docs talk about selinux.  What does this
> even mean on a non-selinux system?

As far as I understand it, sockets have a generic mechanism for storing
one arbitrary security label alongside the uid, and the active LSM gets
to define its syntax and what it means. This is the equivalent of that.

Traditional D-Bus has GetConnectionSELinuxSecurityContext() which only
returns the SELinux context, and never any other LSM's
context/label/profile/whatever.

suggests that it has users; I don't know what they do with it, or
whether they're correct.

The intention was that each LSM with code in dbus-daemon will eventually
contribute a key/value pair to GetConnectionCredentials() rather than
having their own separate methods, with
GetConnectionSELinuxSecurityContext() deprecated, but that's blocked by
people who understand the LSMs contributing the necessary code and
documentation. (Incidentally, if anyone reading this can contribute
proper documentation of the SELinux context to the D-Bus Specification -
what is the preferred jargon term? what do a couple of typical values
look like? is it restricted to some limited character set? etc. - I
would be grateful for a patch.)

Of course, if kdbus ends up being what everyone uses for D-Bus on Linux,
then there will no longer be much point in adding Linux-specific
features to dbus-daemon.

> Otherwise we'll end up with two
> separate selinux policy databases -- the normal one and whatever dbus
> tries to do

Traditional D-Bus already has this problem: dbus-daemon has to work out
"what would SELinux do?" in userland, including the decision whether to
enforce or just complain, and do the same. My understanding is that one
of the more minor upsides of doing (this part of) D-Bus in the kernel is
that it would remove that intermediary, moving the security decisions to
a location where LSMs can allow/deny things directly.

S

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/12] Add kdbus implementation

[Simon McVittie]

On 30/10/14 11:52, Tom Gundersen wrote:
> For example, if you want to get the audit identity
> bits, you can now get this attached securely by the kernel, at the
> time the message is sent, rather than having to firest get the peer's
> $PID from SCM_CREDENTIALS and then read the audit identity bits racily
> from /proc/$PID/loginuid and /proc/$PID/sessionid

... which dbus-daemon (traditional D-Bus) deliberately doesn't offer as
a feature, because we are not aware of any way to do that over Unix
sockets without a race condition; and if we can't have it securely, we
don't want to have it at all.

It would be great if kdbus can fix that omission.

Capabilities are in the same boat, and as a result, systemd can't
currently have D-Bus methods that can only be called with CAP_WHATEVER.

> * fewer userspace context switches
[...]
> * fewer message copies in userspace

Readers are probably already aware of this, but note that D-Bus is
designed to be usable between mutually distrusting processes, which is
why we use Unix sockets and a lot of copies, rather than mmap or something.

S

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kdbus: add code for buses, domains and endpoints

[Simon McVittie]

On 30/10/14 18:08, Djalal Harouni wrote:
> So, this is similar to AF_UNIX sockets. For them there's SCM_CREDENTIALS
> and SO_PEERCRED. The former uses credentials at the time of when
> messages are being sent, the latter uses the credentials at the time
> when when the connection was initially established.

Please note that dbus-daemon, the reference implementation of D-Bus,
does not actually ever use SCM_CREDENTIALS on its AF_UNIX sockets. We
prefer to use Linux's SO_PEERCRED, or the platform's closest available
equivalent if there is one. dbus-daemon has methods (RPC calls) to get a
specified peer's uid, pid or LSM data (e.g. SELinux context), but those
methods return the value that was true when the connection was opened or
shortly afterwards, not the value that is true right now. I believe the
plan is that kdbus has ioctls that are equivalent to those RPC calls,
but without needing to wait for asynchronous socket events to get an answer.

The reason I say "or shortly afterwards" is that for the benefit of
platforms where the "best" credentials transfer mechanism behaves like
Linux SCM_CREDENTIALS, such as FreeBSD's SCM_CREDS, the beginning of a
D-Bus protocol stream is that the client sends '\0' to dbus-daemon,
accompanied by SCM_CREDS or whatever if the platform needs it. On Linux
we just send a plain '\0' with no out-of-band data at that point.

The only out-of-band data we send with individual D-Bus RPC messages
later in the connection's lifetime is for fd-passing (SCM_RIGHTS).

It would be a perfectly reasonable feature request to have individual
D-Bus messages that contain proof that, *at the time of sending*, the
sender possessed a given uid/pid/gid/capability/whatever, but we do not
currently have that feature. It would be reasonable for kdbus to have
that feature even though traditional D-Bus doesn't, and it's entirely
possible that it is a feature that would be of benefit for e.g. systemd,
but it is not required for feature parity with traditional D-Bus over
AF_UNIX; it should be included in kdbus, or not, on its own merits.

S

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kdbus: add code to gather metadata

[Simon McVittie]

On 01/11/14 16:19, Andy Lutomirski wrote:
> You can't justify logging fundamentally unverifiable things like the
> command line by saying that you want to know if someone tries to play
> (impossible-to-reliably-detect) games to obscure their command line.

I think kdbus might be mixing up two orthogonal things here.

It has an easy, kernel-checked, race-free way to determine
kernel-mediated credential-like information that cannot be faked or
interfered with (uid, primary gid, other gids?, security label,
capabilities) because these are usable for security decisions, but if
they are *not* received in a kernel-checked, race-free way, then they
are useless.

One concrete example of using non-ucred credential-like information is
that traditional D-Bus can only restrict sysadmin tasks to uid 0 (or a
root-equivalent uid in group sudo/admin/whatever), whereas when systemd
and systemd-logind are run on kdbus, many of their D-Bus methods require
specific capabilities(7): KillUser requires CAP_KILL, PowerOff requires
CAP_SYS_BOOT, and so on. If capabilities(7) are a good thing, then
that's surely a good thing too. (On the other hand, if you think
capabilities(7) are a waste of time, then so is this.)

It also uses the same mechanism as an easy, race-free, but *not*
kernel-checked way to determine bits and pieces that are valuable for
debugging (dbus-monitor etc.), but unsuitable for security decisions,
such as cmdline.

In traditional D-Bus, you can get the uid and pid of a remote process,
but in a debug log you would probably actually prefer to log the cmdline
in addition; yes a malicious user could fake the cmdline, but when
debugging a system problem, information that is known to be forgeable
seems better than no information at all. After all, ps(1) shows the
forgeable cmdline, not just the executable. You can get that by
rummaging in /proc/$pid, but there is a race: if the remote process
exits too soon (a "fire and forget" method call) then you'll never know
who it was. kdbus solves that race, but does not make cmdline unforgeable.

If client libraries wishing to attach their cmdline (or other debug
info) to messages for debugging were required to add it as an
out-of-band KDBUS_ITEM, or as a D-Bus message header inside the payload,
then that would be duplicating work in client libraries that could have
been done centrally, but would still solve the race.

S

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Trusted kernel patchset

[Simon McVittie]

On 16/03/15 21:29, Kees Cook wrote:
> I really think "trusted" is the right term here. It's about as
> accurate as possible for what this flag means.

A subtlety that might make this clearer: there isn't really such a thing
as "trusted" in isolation, only "trusted by..." a specific other party;
and in this case, as far as I can see, the intended meaning is  that
lower layers (firmware and/or bootloader) have been configured to trust
this particular kernel.

It doesn't mean "user-space can trust me not to do bad things", because
any kernel, malicious or otherwise, could indeed easily claim that; and
if it is lying, what is user-space going to do about it anyway? Rather,
it means "the firmware is trusting me not to do things it would consider
bad".

I assume the intention isn't that it will make privileged bits of
userland be more careful to avoid breaking this trust assumption,
because the point of this patchset seems to be to make it impossible
(modulo bugs) for userland to do that.

Is the intention instead that it will make privileged bits of userland
more careful to avoid breaking the trust chain in ways that would "fail
safe" by refusing to boot?

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Trusted kernel patchset

[Simon McVittie]

On 17/03/15 20:42, Matthew Garrett wrote:
> On Tue, 2015-03-17 at 20:22 +0000, Simon McVittie wrote:
>> Is the intention instead that it will make privileged bits of userland
>> more careful to avoid breaking the trust chain in ways that would "fail
>> safe" by refusing to boot?
> 
> Not really. It's intended to avoid the situation where privileged
> userspace is able to modify the running kernel to an extent that's
> broadly equivalent to booting an arbitrary kernel.

Sorry, I was imprecise about what I meant by "it". I understand that the
intention of the patchset as a whole is to prevent privileged userspace
from subverting the kernel; I was asking about the intention of the
ability to read from /sys/kernel/security/trusted_kernel.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

[Simon McVittie]

On 02/02/16 17:34, David Herrmann wrote:
> Furthermore, with this patch in place, a process better not pass any
> file-descriptors to an untrusted process.
...
> Did anyone notify the dbus maintainers of this? They
> might wanna document this, if not already done (CC: smcv).

Sorry, I'm not clear from this message on what patterns I should be
documenting as bad, and what the effect of non-compliance would be.

dbus-daemon has a fd-passing feature, which uses AF_UNIX sockets'
existing ability to pass fds to let users of D-Bus attach fds to their
messages. The message is passed from the sending client to dbus-daemon,
then from dbus-daemon to the recipient:

 AF_UNIX AF_UNIX
   ||
sender ---> dbus-daemon ---> recipient
   ||

This has been API since before I was a D-Bus maintainer, so I have no
influence over its existence; just like the kernel doesn't want to break
user-space, dbus-daemon doesn't want to break its users.

The system dbus-daemon (dbus-daemon --system) is a privilege boundary,
and accepts senders and recipients with differing privileges. Without
configuration, messages are denied by default. Recipients can open this
up (by installing system-wide configuration) to allow arbitrary
processes to send messages to them, so that they can carry out their own
discretionary access control. Since 2014, the system dbus-daemon accepts
up to 16 file descriptors per message by default.

There is also a session or user dbus-daemon (dbus-daemon --session) per
uid, but that isn't normally a privilege boundary, so any user trying to
carry out a denial of service there is only hurting themselves.

Am I right in saying that the advice I give to D-Bus users should be
something like this?

* system services should not send fds at all, unless they trust the
  dbus-daemon
* system services should not send fds via D-Bus that will be delivered
  to recipients that they do not trust
* sending fds to an untrusted recipient would enable that recipient to
  carry out a denial-of-service attack (on what? the sender? the
  dbus-daemon?)

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

[Simon McVittie]

On 03/02/16 11:56, David Herrmann wrote:
> However, with Hannes' revised patch, a different DoS attack against
> dbus-daemon is possible. Imagine a peer that receives batches of FDs,
> but never dequeues them. They will be accounted on the inflight-limit
> of dbus-daemon, as such causing messages of independent peers to be
> rejected in case they carry FDs.
> Preferably, dbus-daemon would avoid queuing more than 16 FDs on a
> single destination (total). But that would require POLLOUT to be
> capped by the number of queued fds. A possible workaround is to add
> CAP_SYS_RESOURCE to dbus-daemon.

We have several mitigations for this:

* there's a limit on outgoing fds queued inside dbus-daemon for a
  particular recipient connection, currently 64, and if that's
  exceeded, we stop accepting messages for that recipient, feeding back
  a send failure to the sender for messages to that recipient;
* there's a time limit for how long any given fd can stay queued up
  inside dbus-daemon, currently 2.5 minutes, and if that's exceeded, we
  drop the message;
* if started as root[1], we increase our fd limit to 64k before
  dropping privileges to the intended uid, which in combination with
  the maximum of 256 connections per uid and 64 fds per connection means
  it takes multiple uids working together to carry out a DoS;
* all of those limits can be adjusted by a local sysadmin if necessary,
  if their users are particularly hostile (for instance 16 fds per
  message is a generous limit intended to avoid unforeseen breakage,
  and 4 would probably be enough in practice)

The queueing logic is fairly involved, so I'd appreciate suggested
patches on freedesktop.org Bugzilla or to
dbus-secur...@lists.freedesktop.org if you have an idea for better
limits. If you believe you have found a non-public vulnerability, please
mark any Bugzilla bugs as restricted to the D-Bus security group.

Thanks,
S

[1] The system dbus-daemon is started as root (and hence able to
increase its own fd limit) on all systemd systems, anything that uses
the Red Hat or Slackware sysvinit scripts bundled with dbus, and any
Debian derivatives that use sysvinit and have taken security updates
from at least Debian 7. Other distro-specific init system glue is up to
the relevant distro.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>