(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 :-)