Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)
From: Andy Lutomirski
Date: Mon Aug 31 2015 - 11:38:02 EST
On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote:
> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>> I spotted this:
>> + * kdbus_proc_permission() - check /proc permissions on target pid
>> + * @pid_ns: namespace we operate in
>> + * @cred: credentials of requestor
>> + * @target: target process
>> + *
>> + * This checks whether a process with credentials @cred can access information
>> + * of @target in the namespace @pid_ns. This tries to follow /proc permissions,
>> + * but is slightly more restrictive.
>> + *
>> + * Return: The /proc access level (KDBUS_META_PROC_*) is returned.
>> + */
>> +static unsigned int kdbus_proc_permission(const struct pid_namespace *pid_ns,
>> + const struct cred *cred,
>> + struct pid *target)
>> That code ended up in a pull request, although AFAICT it was never in
>> any patch email sent to me or to any public mailing list. I suspect
>> it was at least partially a response to one of my old reviews.
> Exactly. It's an attempt to model metadata access similar to /proc
> access (thus, access to kdbusfs implies access to procfs, but not vice
> versa (nor any implication on hidepid)).
I haven't looked at what calls this function, but I guess the model is
inaccurate and errs in the too-permissive direction.
Fedora actually labels inodes in /proc (ls -Zd /proc/???, for
example), but I don't know what it does with those labels.
>> I haven't checked the context in which it's used, but in order for
>> kdbus_proc_permission to do what it claims to do, it appears to be
>> missing calls to security_inode_permission and
> Both are expected to be added by lsm patches (both hooks you mentioned
> are empty if no lsm is selected).
Will that mean that existing MAC policies stop being fully enforced
(in effect) if kdbus is installed?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/