linux-kernel - Re: RFC(v2): Audit Kernel Container IDs

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: <1508255091.3129.27.camel@HansenPartnership.com>
Date:   Tue, 17 Oct 2017 08:44:51 -0700
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Simo Sorce <simo@...hat.com>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Steve Grubb <sgrubb@...hat.com>, linux-audit@...hat.com
Cc:     mszeredi@...hat.com, trondmy@...marydata.com, jlayton@...hat.com,
        Linux API <linux-api@...r.kernel.org>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        Carlos O'Donell <carlos@...hat.com>, cgroups@...r.kernel.org,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Andy Lutomirski <luto@...nel.org>,
        Linux Network Development <netdev@...r.kernel.org>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        Eric Paris <eparis@...isplace.org>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: RFC(v2): Audit Kernel Container IDs

On Tue, 2017-10-17 at 11:28 -0400, Simo Sorce wrote:
> > Without a *kernel* policy on containerIDs you can't say what
> > security policy is being exempted.
> 
> The policy has been basically stated earlier.
> 
> A way to track a set of processes from a specific point in time
> forward. The name used is "container id", but it could be anything.
> This marker is mostly used by user space to track process hierarchies
> without races, these processes can be very privileged, and must not
> be allowed to change the marker themselves when granted the current
> common capabilities.
> 
> Is this a good enough description ? If not can you clarify your
> expectations ?

I think you mean you want to be able to apply a label to a process
which is inherited across forks.  The label should only be susceptible
to modification by something possessing a capability (which one TBD).
 The idea is that processes spawned into a container would be labelled
by the container orchestration system.  It's unclear what should happen
to processes using nsenter after the fact, but policy for that should
be up to the orchestration system.

The label will be used as a tag for audit information.

I think you were missing label inheritance above.

The security implications are that anything that can change the label
could also hide itself and its doings from the audit system and thus
would be used as a means to evade detection.  I actually think this
means the label should be write once (once you've set it, you can't
change it) and orchestration systems should begin as unlabelled
processes allowing them to do arbitrary forks.

For nested containers, I actually think the label should be
hierarchical, so you can add a label for the new nested container but
it still also contains its parents label as well.

James