linux-kernel - Re: [PATCH v5 14/16] ima: Use mac_admin_ns_capable() to check corresponding capability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <985818fabf3ed1478fd53cb4dd48162fff132492.camel@linux.ibm.com>
Date:   Sat, 11 Dec 2021 11:00:42 -0500
From:   James Bottomley <jejb@...ux.ibm.com>
To:     Stefan Berger <stefanb@...ux.ibm.com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Denis Semakin <denis.semakin@...wei.com>
Cc:     "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "zohar@...ux.ibm.com" <zohar@...ux.ibm.com>,
        "christian.brauner@...ntu.com" <christian.brauner@...ntu.com>,
        "containers@...ts.linux.dev" <containers@...ts.linux.dev>,
        "dmitry.kasatkin@...il.com" <dmitry.kasatkin@...il.com>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
        Krzysztof Struczynski <krzysztof.struczynski@...wei.com>,
        Roberto Sassu <roberto.sassu@...wei.com>,
        "mpeters@...hat.com" <mpeters@...hat.com>,
        "lhinds@...hat.com" <lhinds@...hat.com>,
        "lsturman@...hat.com" <lsturman@...hat.com>,
        "puiterwi@...hat.com" <puiterwi@...hat.com>,
        "jamjoom@...ibm.com" <jamjoom@...ibm.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "paul@...l-moore.com" <paul@...l-moore.com>,
        "rgb@...hat.com" <rgb@...hat.com>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "jmorris@...ei.org" <jmorris@...ei.org>
Subject: Re: [PATCH v5 14/16] ima: Use mac_admin_ns_capable() to check
 corresponding capability

On Sat, 2021-12-11 at 10:38 -0500, Stefan Berger wrote:
> On 12/11/21 10:02, Serge E. Hallyn wrote:
> > IMO yes it is unsafe, however I concede that I am not sufficiently
> > familiar with the policy language.  At least Stefan and Mimi (IIUC)
> > want the host policy language to be able to specify cases where an
> > IMA ns can be configured.  What's not clear to me is what sorts of
> > triggers the host IMA policy could specify that would safely
> > identify a IMA ns generation
> > trigger.
> > 
> > Stefan, would you mind showing what such a policy statement would
> > look like? Does it amount to "/usr/bin/runc may create an IMA ns
> > which escapes current policy" ?  Or is it by UID, or any file which
> > has a certain xattr on it?
> 
> If this policy here is active on the host then file executions 
> (BPRM_CHECK) of uid=0 should be measured and audited on the host in
> any IMA namespace that uid=0 may create. We achieve this with
> hierarchical processing (v6: 10/17).
> 
> measure func=BPRM_CHECK mask=MAY_EXEC uid=0
> 
> audit func=BPRM_CHECK mask=MAY_EXEC uid=0

Or perhaps to put another way that might be more useful to unprivileged
containers: if you strip the uid=0 from both of those statements, you
get a rule that logs and audits any execution.  Once you enter the IMA
namespace, in that namespace you see nothing, but outside the parent is
still logging and auditing all executions, including those inside the
container, according to its measure/audit all executions rule.  The
container can't turn that off by writes to its policy file.

So the container can never escape any policy rule imposed by the parent

James