From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752162AbcGLN31 (ORCPT ); Tue, 12 Jul 2016 09:29:27 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:54140 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750999AbcGLN3Z (ORCPT ); Tue, 12 Jul 2016 09:29:25 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Topi Miettinen Cc: linux-kernel@vger.kernel.org, pmladek@suse.com, luto@kernel.org, serge@hallyn.com, keescook@chromium.org, Paul Moore , Eric Paris , Tejun Heo , Li Zefan , Johannes Weiner , "moderated list\:AUDIT SUBSYSTEM" , "open list\:CONTROL GROUP \(CGROUP\)" , "open list\:CAPABILITIES" References: <1468235672-3745-1-git-send-email-toiwoton@gmail.com> <87vb0bbzyo.fsf@x220.int.ebiederm.org> Date: Tue, 12 Jul 2016 08:16:51 -0500 In-Reply-To: (Topi Miettinen's message of "Tue, 12 Jul 2016 08:54:41 +0000") Message-ID: <878tx79et8.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bMxkU-0004zR-Uw;;;mid=<878tx79et8.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18Radcp+3VMiXu+M5w7RIigI1lPu9Dtq+w= X-SA-Exim-Connect-IP: 67.3.204.119 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa02 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Topi Miettinen X-Spam-Relay-Country: X-Spam-Timing: total 968 ms - load_scoreonly_sql: 0.08 (0.0%), signal_user_changed: 11 (1.2%), b_tie_ro: 5 (0.5%), parse: 1.87 (0.2%), extract_message_metadata: 7 (0.7%), get_uri_detail_list: 2.9 (0.3%), tests_pri_-1000: 8 (0.8%), tests_pri_-950: 2.3 (0.2%), tests_pri_-900: 1.87 (0.2%), tests_pri_-400: 36 (3.7%), check_bayes: 34 (3.5%), b_tokenize: 12 (1.3%), b_tok_get_all: 9 (1.0%), b_comp_prob: 4.5 (0.5%), b_tok_touch_all: 2.9 (0.3%), b_finish: 1.00 (0.1%), tests_pri_0: 869 (89.8%), check_dkim_signature: 1.04 (0.1%), check_dkim_adsp: 4.9 (0.5%), tests_pri_500: 9 (0.9%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] capabilities: audit capability use X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Topi Miettinen writes: > On 07/11/16 21:57, Eric W. Biederman wrote: >> Topi Miettinen writes: >> >>> There are many basic ways to control processes, including capabilities, >>> cgroups and resource limits. However, there are far fewer ways to find >>> out useful values for the limits, except blind trial and error. >>> >>> Currently, there is no way to know which capabilities are actually used. >>> Even the source code is only implicit, in-depth knowledge of each >>> capability must be used when analyzing a program to judge which >>> capabilities the program will exercise. >>> >>> Generate an audit message at system call exit, when capabilities are used. >>> This can then be used to configure capability sets for services by a >>> software developer, maintainer or system administrator. >>> >>> Test case demonstrating basic capability monitoring with the new >>> message types 1330 and 1331 and how the cgroups are displayed (boot to >>> rdshell): >> >> You totally miss the interactions with the user namespace so this won't >> give you the information you are aiming for. > > Please correct me if this is not right: > > There are two cases: > a) real capability use as seen outside the namespace > b) use of capabilities granted by the namespace > Both cases could be active independently. > > For auditing purposes, we're mostly interested in a) and log noise from > b) could be even seen a distraction. > > For configuration purposes, both cases can be interesting, a) for the > configuration of services and b) in case where the containerized > configuration is planned to be deployed outside. I'd still only log > a). > > > The same logic should apply with cgroup namespaces. Not logging capabilities outside of the initial user namespace is certainly the conservative place to start, and what selinux does. You should also be logging capability use from cap_capable. Not ns_capable. You are missing several kinds of capability use as a quick review of kernel/capability.c should have shown you. Eric