Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753432AbbHaPh6 (ORCPT ); Mon, 31 Aug 2015 11:37:58 -0400 Received: from mail-oi0-f43.google.com ([209.85.218.43]:33449 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753021AbbHaPh4 (ORCPT ); Mon, 31 Aug 2015 11:37:56 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Mon, 31 Aug 2015 08:37:36 -0700 Message-ID: Subject: Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg) To: David Herrmann Cc: "linux-kernel@vger.kernel.org" , Greg KH Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2268 Lines: 54 On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann wrote: > Hi > > On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski 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 >> security_file_permission. > > 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? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/