linux-kernel - Re: [RFC 04/11] ima: add support to namespace securityfs file

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]

Date:   Thu, 25 May 2017 07:46:02 -0400
From:   Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:     John Johansen <john.johansen@...onical.com>,
        Guilherme Magalhaes <guilherme.magalhaes@....com>,
        dmitry.kasatkin@...il.com
Cc:     viro@...iv.linux.org.uk, james.l.morris@...cle.com,
        serge@...lyn.com, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-ima-devel@...ts.sourceforge.net,
        linux-ima-user@...ts.sourceforge.net,
        linux-security-module@...r.kernel.org, tycho@...ker.com,
        joaquims@....com, nigel.edwards@....com
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 <guilherme.magalhaes@....com>
> > 
> > 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