On 7/9/2015 3:22 PM, David Herrmann wrote: > Hi > > On Thu, Jul 9, 2015 at 8:26 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote: >> Hi, >> >> I have a concern with the support for faked credentials in kdbus, but >> don't know enough about the original motivation or intended use case to >> evaluate it concretely. I raised this issue during the "kdbus for >> 4.1-rc1" thread a while back but none of the kdbus maintainers >> responded, > Sorry, some mails might have been gone unanswered in that huge thread. > Please feel free to ping us about anything we didn't comment on. See > below.. > >> and the one D-BUS maintainer who did respond said that there >> is no API in dbus-daemon for faking client credentials, so this is not >> something inherited from dbus-daemon or required for compatibility with it. >> >> First, I have doubts as to whether there should be any way to fake the >> seclabel, no matter how "privileged" the caller. Unless there is a >> clear use case for that functionality, I would prefer to see it dropped >> altogether. >> >> Second, IIUC, the ability to fake any portion of the credentials or pids >> is granted if the caller either has CAP_IPC_OWNER or owns the bus (uid >> match). Clearly that isn't sufficient basis for seclabel faking, and it >> seems questionable as to whether it should be sufficient for faking any >> of the other credentials or pids. Compare with e.g. >> net/core/scm.c:scm_check_creds() logic for faking credentials on a Unix >> domain socket, which requires CAP_SYS_ADMIN for faking pid, CAP_SETUID >> for faking any of the uid fields, and CAP_SETGID for faking any of the >> gid fields. >> >> Thanks for any light you can shed on the matter. > To be clear, faking metadata has one use-case, and one use-case only: > dbus1 compatibility > > In dbus1, clients connect to a unix-socket placed in the file-system > hierarchy. To avoid breaking ABI for old clients, we support a > unix-kdbus proxy. This proxy is called systemd-bus-proxyd. It is > spawned once for each bus we proxy and simply remarshals messages from > the client to kdbus and vice versa. > > With dbus1, clients can ask the dbus-daemon for the seclabel of a peer > they talk to. They're free to use this information for any purpose. On > kdbus, we want to be compatible to dbus-daemon. Therefore, if a native > client queries kdbus for the seclabel of a peer behind a proxy, we > want that query to return the actual seclabel of the peer, not the > seclabel of the proxy. Same applies to PIDS and CREDS. > > This faked metadata is never used by the kernel for any security > decisions. It's sole purpose is to return them if a native kdbus > client queries another peer. Furthermore, this information is never > transmitted as send-time metadata (as it is, in no way, send-time > metadata), but only if you explicitly query the connection-time > metadata of a peer (KDBUS_CMD_CONN_INFO). > > Regarding requiring CAP_SYS_ADMIN, I don't really see the point. In > the kdbus security model, if you don't trust the bus-creator, you > should not connect to the bus.
That's fine in a discretionary access control model, but not in a mandatory access control model. The decision on trust of the "other" guy is never up to the process, it's up to the mandatory access control policy. > A bus-creator can bypass kdbus > policies, sniff on any transmission and modify bus behavior. It just > seems logical to bind faked-metadata to the same privilege. However, I > also have no strong feeling about that, if you place valid points. So > please elaborate. Smack has to require CAP_MAC_ADMIN to allow a process to fake Smack metadata. This is exactly what CAP_MAC_ADMIN is for. Changing Smack metadata is considered a hugely dangerous activity. > But, please be aware that if we require privileges to fake metadata, > then you need to have such privileges to provide a dbus1 proxy for > your native bus on kdbus. In other words, users are able to create > session/user buses, but they need CAP_SYS_ADMIN to spawn the dbus1 > proxy. This will have the net-effect of us requiring to run the proxy > as root (which, I think, is worse than allowing bus-owners to fake > _connection_ metadata). I disagree with you strongly. Allowing a bus owner to fake connection metadata is insane. If you're going to allow it it should frigging well require privilege. You're allowing the program to *lie* about information that an unsuspecting client may use to make important decisions. Go ahead and cry "backward compatibility". Two wrongs don't make a right. > > Thanks > David > -- 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/
