[Bug 75602]

[Simon McVittie]

(In reply to comment #16)
> I'll revisit this patch and address all your concerns focusing
> only on EXTERNAL authentication and supplementary groups.  My other goal is
> also try to not even touch /etc/{passwd,group} at all if not absolutely
> necessary.

Great. If you can get this working well and securely, I'm happy to
review/merge.

Regarding setuid:

> If an account has access to setuid/setgid executables and is available to
> potentially rogue users, then the system is flawed, not D-Bus.

They don't have to be setuid executables that do anything inherently
unsafe on their own. su, sudo or pkexec is enough for the attack I
described: as long as its uid is 0 at the time that the dbus-daemon
looks at it, it doesn't matter that all it was doing is sitting at an
"enter password:" prompt.

Even if *your* system does not have any setuid executables, general-
purpose Unix does - su, sudo, pkexec are easy examples - and D-Bus is
meant to be functional and secure on general-purpose Unix, and in
particular, general-purpose Linux.

Now, this attack is mostly about what happens if you check credentials
per-message instead of per-connection, which you're not doing, so the
most straightforward version of the attack is avoided. I'm working on
the assumption that for bad things to happen, the client will have to
send a message. If it exec()s a privileged executable, it "has lost
control" and can no longer send "bad messages".

However, I'm concerned about the possibility of a client queueing up its
side of the entire authentication handshake, the Hello message, and a
"bad message" into the socket's buffer, then exec()ing; is it possible
that the server could perform the /proc check, see the exec()'d
executable's credentials, and then act on the rest of the pre-queued
data from the *original* executable?

One way to avoid this would be to avoid the /proc stuff, and instead
extend the authentication handshake with a new verb similar to
NEGOTIATE_UNIX_FD:

    C: AUTH EXTERNAL 31303030
    S: OK
    C: I_AM_IN_GROUP 100
    S: OK
    C: I_AM_IN_GROUP 101
    S: OK
    C: BEGIN

where the first message of I_AM_IN_GROUP is accompanied by
SCM_CREDENTIALS out-of-band data containing the corresponding gid.
That's likely to be somewhat more difficult than rummaging in /proc,
though.

> * cp /bin/bash audiobash && chgrp audio audiobash && chmod g+s audiobash
> 
> The user must be a member of `audio' group in order to chgrp a file to that
> group.  Why then ever bother with these tricks if the user is a *genuine*
> member of the group?

Please read Comment #9 if you're unfamiliar with Unix group semantics -
they are not what you might think they are.

If a user is not (according to /etc/group) a member of audio, but their
shell has the audio supplementary group due to pam_group, then they can
escalate from "temporarily in audio group" to "permanently able to get
into audio group" by copying a shell (or anything similar) and chmod'ing
it g+s. This makes session groups not very useful as a security measure
on general-purpose Unix (they can be secure on a system where users
cannot write to any filesystem mounted without nosuid and/or noexec, but
D-Bus is not restricted to those systems).

> Again, no setuid/setgid should be available.  In this instance `ping'
> program should have cap_net_admin and cap_net_raw capabilities set.  No UID
> change.

I admit that ping is a bad example; substitute anything that, in order
to perform its desired function, has to be setuid-root and world-
executable (or setgid to a desired group, for group-based permissions).
su is a particularly prominent example.

> WRT the other question where you consider different groups in /etc/group and
> in procfs, my opinion is that those in /etc/group should be ignored.  My
> view is that someone knew better and since they were privileged enough to
> convince kernel to set those groups on the process, libdbus in this instance
> should respect that.

Fair enough. This is the option that's more likely to break existing
applications (which could be relying on the "I get my uid's groups from
/etc/group" semantics), but I don't think it'll break anything in
practice.

> Now again you could argue that there's a race condition here and someone was
> able to gain group membership the same way as for UID.

Perhaps. If there is one, please address it, if not, convince me of that
fact?

> I think it's up to
> the system administrator/architect to provide or deny such opportunity.  For
> example the system I work on has all D-Bus services/clients running in their
> individual sandboxes where one of the features is a separate mount namespace
> with all filesystems mounted either ro,nosuid or noexec.

That's great for your system, but in a general-purpose Unix distribution
this is rarely an option, and I'm not willing to make D-Bus insecure
when used in a general-purpose distribution.

> * D-Bus configuration
>   If someone is able to configure D-Bus to use this feature (presumably this
> would be a
>   system administrator) then they are confident enough about their system
> and should be
>   allowed to use this feature.

I'm reluctant to add configuration options that are only safe to use on
heavily-locked-down systems, and when enabled on a general-purpose Unix
system, subtly undermine system security. Security is quite hard enough
already without my help :-)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dbus in Ubuntu.
https://bugs.launchpad.net/bugs/75602

Title:
  DBUS Should Support "Session Groups"
  (pam_group.so,/etc/security/groups.conf)

Status in D-Bus:
  In Progress
Status in “dbus” package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: dbus

  In my lab, there are lots of users in an LDAP database. These users
  are assigned to the groups audio,video,plugdev,etc. by pam_group
  (using the /etc/security/groups.conf file). The problem is, DBUS
  doesn't recognize users as being in groups unless they're in
  /etc/group, which isn't practical for our setup. So, there are
  permission problems with USB sticks, kpowersave, etc. (well, there
  *will* be, once I upgrade from Dapper to a more version of Kubuntu).

  On my laptop, I can use (the kludge) "adduser $uname plugdev"... this
  won't work in the lab.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/75602/+subscriptions