linux-kernel - Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances

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: <12675437.ssZNCck7zG@sifl>
Date:	Thu, 14 May 2015 15:19:33 -0400
From:	Paul Moore <pmoore@...hat.com>
To:	Steve Grubb <sgrubb@...hat.com>,
	Richard Guy Briggs <rgb@...hat.com>, ebiederm@...ssion.com
Cc:	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, linux-audit@...hat.com,
	eparis@...isplace.org, arozansk@...hat.com, serge@...lyn.com,
	zohar@...ux.vnet.ibm.com, viro@...iv.linux.org.uk,
	linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances

On Thursday, May 14, 2015 10:57:14 AM Steve Grubb wrote:
> On Tuesday, May 12, 2015 03:57:59 PM Richard Guy Briggs wrote:
> > On 15/05/05, Steve Grubb wrote:
> > > I think there needs to be some more discussion around this. It seems
> > > like this is not exactly recording things that are useful for audit.
> > 
> > It seems to me that either audit has to assemble that information, or
> > the kernel has to do so.  The kernel doesn't know about containers
> > (yet?).
> 
> Auditing is something that has a lot of requirements imposed on it by
> security standards. There was no requirement to have an auid until audit
> came along and said that uid is not good enough to know who is issuing
> commands because of su or sudo. There was no requirement for sessionid
> until we had to track each action back to a login so we could see if the
> login came from the expected place.
> 
> What I am saying is we have the same situation. Audit needs to track a
> container and we need an ID. The information that is being logged is not
> useful for auditing. Maybe someone wants that info in syslog, but I doubt
> it. The audit trail's purpose is to allow a security officer to reconstruct
> the events to determine what happened during some security incident.

As Eric, and others, have stated, the container concept is a userspace idea, 
not a kernel idea; the kernel only knows, and cares about, namespaces.  This 
is unlikely to change.

However, as Steve points out, there is precedence for the kernel to record 
userspace tokens for the sake of audit.  Personally I'm not a big fan of this 
in general, but I do recognize that it does satisfy a legitimate need.  Think 
of things like auid and the sessionid as necessary evils; audit is already 
chock full of evilness I doubt one more will doom us all to hell.

Moving forward, I'd like to see the following:

* Record the creation/removal/mgmt of the individual namespaces as Richard's 
patchset currently does.  However, I'd suggest using an explicit namespace 
value for the init namespace instead of the "unset" value in the V6 patchset 
(my apologies if you've already changed this Richard, I haven't looked at V7 
yet).

* Create a container ID token (unsigned 32-bit integer?), similar to 
auid/sessionid, that is set by userspace and carried by the kernel to be used 
in audit records.  I'd like to see some discussion on how we manage this, e.g. 
how do handle container ID inheritance, how do we handle nested containers 
(setting the containerid when it is already set), do we care if multiple 
different containers share the same namespace config, etc.?

* When userspace sets the container ID, emit a new audit record with the 
associated namespace tokens and the container ID.

* Look at our existing audit records to determine which records should have 
namespace and container ID tokens added.  We may only want to add the 
additional fields in the case where the namespace/container ID tokens are not 
the init namespace.

Can we all live with this?  If not, please suggest some alternate ideas; 
simply shouting "IT'S ALL CRAP!" isn't helpful for anyone ... it may be true, 
but it doesn't help us solve the problem ;)

-- 
paul moore
security @ redhat

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/