The kdbuswreck

The kdbuswreck

You've basically just described the way BSDAuth works, as used on OpenBSD. Except BSDAuth uses setuid and setgid executables, and it doesn't need a separate root-privileged daemon. Because PAM modules all run in the same process, that process must execute as root to satisfy the needs of every module. Whereas BSDAuth uses a separate executable as it's "module", which communicates using a simple protocol over a pipe. Each module can have minimal privileges. Some modules are setuid root, others are setgid to a group with write permissions to the specific database. To be able to execute any of the login modules, you only need to be in the auth group. So if I wanted to write a web application that was able to check passwords using the system authentication, I only need to put the process (the HTTP daemon, or a separate process) into the auth group. Everything else is hidden behind a very simple C API.

$ sudo ls -ld /usr/libexec/auth/
drwxr-x---  2 root  auth  512 Apr 22 15:00 /usr/libexec/auth/

$ sudo ls -l /usr/libexec/auth/                                      
total 380
-r-xr-sr-x  4 root  _token   14.8K Aug  7  2014 login_activ
-r-sr-xr-x  1 root  auth     19.5K Aug  7  2014 login_chpass
-r-xr-sr-x  4 root  _token   14.8K Aug  7  2014 login_crypto
-r-sr-xr-x  1 root  auth     15.1K Aug  7  2014 login_lchpass
-r-sr-xr-x  1 root  auth     10.1K Aug  7  2014 login_passwd
-r-xr-sr-x  1 root  _radius  14.5K Aug  7  2014 login_radius
-r-xr-xr-x  1 root  auth      9.9K Aug  7  2014 login_reject
-r-xr-sr-x  1 root  auth     10.0K Aug  7  2014 login_skey
-r-xr-sr-x  4 root  _token   14.8K Aug  7  2014 login_snk
-r-sr-xr-x  1 root  auth     18.8K Aug  7  2014 login_tis
-r-xr-sr-x  4 root  _token   14.8K Aug  7  2014 login_token
-r-xr-sr-x  1 root  auth     20.5K Aug  7  2014 login_yubikey

I don't disagree with you in principle. I only mean to point out that existing, buzzword-deficient mechanisms still provide much low-hanging fruit that could be better applied to achieve least privilege. I have my fingers crossed that support for Capsicum is eventually merged into the kernel. The recent process descriptor merge (is it still pending?) made me a tad less pessimistic.

Now that I think about it, the same BSDAuth scheme could be applied in the case of kdbus. Because POSIX capabilities are defined by tagging the executable, why not simply make the executable setgid to a group, such as "_reboot". The GID of a process can be queried in a race-free manner using existing credential passing IPC features. Using supplementary groups and small helper executables, you could grant sets of ad hoc capabilities to executables--invoke the helper to make the request, allowing it to inherit your socket. The helper is setuid or setgid to a role which identifies a particular privileges, and restrict invocation to processes based on group (effective or supplementary). (The group owner of the executable could be different from the groups allowed to execute it by placing the executable in restricted directories, similar to /usr/libexec/auth in BSDAuth.)

Alternatively, you could expand the notion of setgid so that you could initialize all the supplementary groups of an executable based on extended attributes of the file. And you could extend credential passing to include supplementary groups. Solaris and OS X already do this! ucred_getgroups on Solaris and getsockopt(LOCAL_PEEREID) on OS X return the supplementary group list along with the effective UID and GID.

Frankly, I don't think such a scheme is all that ugly, especially considering that the counter argument to the concern with overloading of the semantics of kernel capabilities is that in practice the usage scenarios are few and relatively simple. That implies a scheme similar to BSDAuth likewise wouldn't get out-of-hand. It doesn't necessarily require any kernel changes, and is portable to boot!