Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753185Ab1FTPv3 (ORCPT ); Mon, 20 Jun 2011 11:51:29 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:53847 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751356Ab1FTPv1 (ORCPT ); Mon, 20 Jun 2011 11:51:27 -0400 X-Authority-Analysis: v=1.1 cv=yMxAJ7W7nAoPh8ZdbvCArpG6pAdHwgpzIvOq8QbMesM= c=1 sm=0 a=wom5GMh1gUkA:10 a=Z9NF-r3ie7EA:10 a=Rj1_iGo3bfgA:10 a=kj9zAlcOel0A:10 a=g3F5VGk0NOMZWSIEWMgijA==:17 a=XkRKQH6RAAAA:8 a=rPmccLwA9GJN2CUmtIUA:9 a=K_5O1ddBASymVZQtJLQA:7 a=CjuIK1q_8ugA:10 a=QGsFc6kCM0wA:10 wl=env:18 a=g3F5VGk0NOMZWSIEWMgijA==:117 X-Cloudmark-Score: 0 X-Originating-IP: 70.123.158.191 Date: Mon, 20 Jun 2011 10:51:24 -0500 From: "Serge E. Hallyn" To: Vasiliy Kulikov Cc: Serge Hallyn , Eric Paris , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, apparmor@lists.ubuntu.com, "selinux@tycho.nsa.gov Stephen Smalley" , James Morris , Eric Paris , John Johansen , kernel-hardening@lists.openwall.com, serge@hallyn.com, Andrew Morgan Subject: Re: [RFC v2] security: intoduce ptrace_task_may_access_current Message-ID: <20110620155124.GA16444@mail.hallyn.com> References: <20110617171152.GA1389@albatros> <4DFF5795.9080609@redhat.com> <20110620150001.GF12469@mail.hallyn.com> <20110620154429.GA12879@albatros> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110620154429.GA12879@albatros> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1880 Lines: 45 Quoting Vasiliy Kulikov (segoon@openwall.com): > On Mon, Jun 20, 2011 at 10:00 -0500, Serge Hallyn wrote: > > > >diff --git a/kernel/capability.c b/kernel/capability.c > > > >index 283c529..bc9b07f 100644 > > > >--- a/kernel/capability.c > > > >+++ b/kernel/capability.c > > > >@@ -356,6 +356,30 @@ bool capable(int cap) > > > > } > > > > EXPORT_SYMBOL(capable); > > > > > > > >+bool task_capable(struct task_struct *task, int cap) > > > >+{ > > > >+ return ns_task_capable(task,&init_user_ns, cap); > > > >+} > > > >+EXPORT_SYMBOL(task_capable); > > > > > > Why do we keep adding things like task_capable? Can't we just stop > > > adding non-lsm functions and just call the right LSM functions from > > > now on? This is my original comments mostly directed at Serge. I'm > > > to the point where I want to NAK anything new in kernel/capability.c > > > (and yes, I know i'm guilty in the paste) > > > > > > >+bool ns_task_capable(struct task_struct *task, struct user_namespace *ns, int cap) > > > > Can you just use has_ns_capability() at the places where you wanted to > > use your new ns_task_capable()? It won't set PF_SUPERPRIV, but you > > can't set that on another task anyway IIRC. > > has_ns_capability() doesn't touch LSMs, but ns_task_capable() uses > security_task_capable() which uses LSMs. I don't understand what you mean by "doesn't touch LSMs." has_ns_capability() uses security_real_capable() which calls security_ops->capable(). The difference between 'has_capability' and 'capable' functions is that the latter, as implied, have current as the subject, while the former ask about another task. -serge -- 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/