lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ