From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1036518AbdEYTEX (ORCPT ); Thu, 25 May 2017 15:04:23 -0400 Received: from g2t1383g.austin.hpe.com ([15.233.16.89]:43808 "EHLO g2t1383g.austin.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S939089AbdEYTET (ORCPT ); Thu, 25 May 2017 15:04:19 -0400 From: "Magalhaes, Guilherme (Brazil R&D-CL)" To: Mimi Zohar , John Johansen , "dmitry.kasatkin@gmail.com" CC: "viro@zeniv.linux.org.uk" , "james.l.morris@oracle.com" , "serge@hallyn.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-ima-devel@lists.sourceforge.net" , "linux-ima-user@lists.sourceforge.net" , "linux-security-module@vger.kernel.org" , "tycho@docker.com" , "Souza, Joaquim (Brazil R&D-ECL)" , "Edwards, Nigel" Subject: RE: [RFC 04/11] ima: add support to namespace securityfs file Thread-Topic: [RFC 04/11] ima: add support to namespace securityfs file Thread-Index: AQHSyl8Vrpr6+XvZQ0eezT8paqVdKqID/4IAgAC/IoCAAEWVAIAAeklg Date: Thu, 25 May 2017 19:04:06 +0000 Message-ID: References: <1494511203-8397-1-git-send-email-guilherme.magalhaes@hpe.com> <1494511203-8397-5-git-send-email-guilherme.magalhaes@hpe.com> <1495656774.3841.72.camel@linux.vnet.ibm.com> <1495712762.3841.89.camel@linux.vnet.ibm.com> In-Reply-To: <1495712762.3841.89.camel@linux.vnet.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: linux.vnet.ibm.com; dkim=none (message not signed) header.d=none;linux.vnet.ibm.com; dmarc=none action=none header.from=hpe.com; x-originating-ip: [15.211.195.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;CS1PR84MB0215;7:xRyaBopAy1DB5qPpueue1q4vKke0JMhgPZRJAXbQ8J7aV/jkViHQPTbFpqm6OfCMS/txJttOfr8EOrkp7oxSmWj9V9OQuXgQAG+WgevrEvevnBsRujUmC1pWXVpCjrD5J1vJPGYkeKrhqyjcbwUvLlw6SBVjuMPFHJ6fZiPmQUYvlwEIryC53FlKNbZTjdzzYU8Iqz1eKcvSuCIT4MlqHNlFu1WGV/rw5A9xs5Bc09x5UbtYH5aLrTtLpyVLgVaZXQhR9WfErrJHOdBw0G2mfwGhpPVU0x5BzPsAOwLkLhExWq+TzeKV42uoMmzI/pdmCiGKKj7ACQxr0hPfzEJLRA== x-forefront-antispam-report: SFV:SKI;SCL:-1SFV:NSPM;SFS:(10019020)(6009001)(39410400002)(39850400002)(39840400002)(39860400002)(39450400003)(39400400002)(377454003)(24454002)(377424004)(13464003)(4326008)(122556002)(93886004)(478600001)(3280700002)(2501003)(3846002)(2900100001)(33656002)(53936002)(7696004)(3660700001)(229853002)(2950100002)(2906002)(86362001)(189998001)(15650500001)(39060400002)(55016002)(66066001)(74316002)(9686003)(76176999)(54906002)(50986999)(54356999)(6246003)(38730400002)(77096006)(305945005)(6436002)(7736002)(81166006)(8936002)(8676002)(6506006)(53546009)(102836003)(25786009)(5660300001)(6116002)(7416002);DIR:OUT;SFP:1102;SCL:1;SRVR:CS1PR84MB0215;H:CS1PR84MB0294.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; x-ms-traffictypediagnostic: CS1PR84MB0215: x-ms-office365-filtering-correlation-id: 202ccfc3-13cb-48f5-6da1-08d4a3a0d13c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075);SRVR:CS1PR84MB0215; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(143289334528602)(227479698468861)(9452136761055)(42262312472803)(104084551191319)(21532816269658)(146099531331640)(198206253151910)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148);SRVR:CS1PR84MB0215;BCL:0;PCL:0;RULEID:;SRVR:CS1PR84MB0215; x-forefront-prvs: 0318501FAE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2017 19:04:06.5325 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR84MB0215 X-OriginatorOrg: hpe.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v4PJ4b5V028659 Mimi, With the securityfs symlink we would address the case of setting policy inside containers, but we still would need a way to set the IMA policy per namespace outside containers. So, the current proposed interface would address the latter case. As an alternative to symlinks, taking this patch set as base, and still considering setting policy inside containers (or inside namespaces in general), it is possible to bind mount the securityfs files into the containers, but it would be needed to prevent read/write access to the namespaced IMA policy files for processes not running on the same namespace. These mechanisms would not require a change in the proposed design. Do you think these mechanisms are enough for the flexibility you asked? Thanks. -- Guilherme -----Original Message----- From: Mimi Zohar [mailto:zohar@linux.vnet.ibm.com] Sent: quinta-feira, 25 de maio de 2017 08:46 To: John Johansen ; Magalhaes, Guilherme (Brazil R&D-CL) ; dmitry.kasatkin@gmail.com Cc: viro@zeniv.linux.org.uk; james.l.morris@oracle.com; serge@hallyn.com; linux-fsdevel@vger.kernel.org; linux-kernel@vger.kernel.org; linux-ima-devel@lists.sourceforge.net; linux-ima-user@lists.sourceforge.net; linux-security-module@vger.kernel.org; tycho@docker.com; Souza, Joaquim (Brazil R&D-ECL) ; Edwards, Nigel Subject: Re: [RFC 04/11] ima: add support to namespace securityfs file Hi John, On Thu, 2017-05-25 at 00:36 -0700, John Johansen wrote: > On 05/24/2017 01:12 PM, Mimi Zohar wrote: > > On Thu, 2017-05-11 at 10:59 -0300, Guilherme Magalhaes wrote: > >> Creating the namespace securityfs file under ima folder. When a > >> mount namespace id is written to the namespace file, a new folder > >> is created and with a policy file for that specified namespace. > >> Then, user defined policy for namespaces may be set by writing rules to this namespace policy file. > >> With this interface, there is no need to give visibility for the > >> securityfs inside mount namespaces or containers in userspace. > >> > >> Signed-off-by: Guilherme Magalhaes > > > > The design needs to be flexible enough for different types of > > containers, not just for when the orchestration layer provides the > > policy. With this design, the container owner has no control over > > the policy. > > > > One option is that we bind mount the securityfs/policy, so that root > > in the container will be allowed to read/write the policy. At some > > point, we might connect a vTPM to the container so that the > > container owner would be able to get a quote. For now even without > > a vTPM, the same mechanism would allow root within the container to > > read the measurement list. > > > I haven't looked at this enough yet on IMAs end, but another possible > solution is using a symlink and a magic jump_link similar to what nsfs is doing. > > The patch series I posted out a couple of weeks ago > [RFC][Patch 0/3] securityfs: add the ability to support symlinks > > adds symlink support to securityfs, and then patch 3/3 cribs from nsfs > updating apparmorfs to use jump_link to "virtualize" the apparmor > policy directory. This avoids needing to have the bind mount. > > I'll break the patch out more and repost so its easier to see if this > approach might work for IMA. Sorry, I've been meaning to take a look at your patches, but just haven't gotten to it yet.  This approach sounds really promising. thanks, Mimi