[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <559EBCC0.7040604@tycho.nsa.gov>
Date: Thu, 09 Jul 2015 14:26:08 -0400
From: Stephen Smalley <sds@...ho.nsa.gov>
To: Greg KH <gregkh@...uxfoundation.org>,
Daniel Mack <daniel@...que.org>,
Djalal Harouni <tixxdz@...ndz.org>,
lkml <linux-kernel@...r.kernel.org>,
LSM <linux-security-module@...r.kernel.org>,
Paul Osmialowski <p.osmialowsk@...sung.com>,
Casey Schaufler <casey@...aufler-ca.com>,
Paul Moore <paul@...l-moore.com>
Subject: kdbus: credential faking
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, 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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists