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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date:	Fri, 15 May 2015 16:42:38 -0400
From:	Paul Moore <pmoore@...hat.com>
To:	Oren Laadan <orenl@...lrox.com>
Cc:	Richard Guy Briggs <rgb@...hat.com>,
	Steve Grubb <sgrubb@...hat.com>, linux-api@...r.kernel.org,
	Linux Containers <containers@...ts.linux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	viro@...iv.linux.org.uk, linux-audit@...hat.com,
	netdev@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	eparis@...isplace.org, zohar@...ux.vnet.ibm.com,
	Eric Biederman <ebiederm@...ssion.com>
Subject: Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances

On Thursday, May 14, 2015 09:10:56 PM Oren Laadan wrote:
> [focusing on "containers id" - snipped the rest away]
> 
> I am unfamiliar with the audit subsystem, but work with namespaces in other
> contexts. Perhaps the term "container" is overloaded here. The definition
> suggested by Steve in this thread makes sense to me: "a combination of
> namespaces". I imagine people may want to audit subsets of namespaces.
> 
> For namespaces, can use a string like "A:B:C:D:E:F" as an identifier for a
> particular combination, where A-F are respective namespaces identifiers.
> (Can be taken for example from /proc/PID/ns/{mnt,uts,ipc,user,pid,net}).
>  That will even be grep-able to locate records related to a particular
> subset
> of namespaces. So a "container" in the classic meaning would have all A-F
> unique and different from the init process, but processes separated only by
> e.g. mnt-ns and net-ns will differ from the init process in  A and F.
> 
> (If a string is a no go, then perhaps combine the IDs in a unique way into a
> super ID).

As has been mentioned in every other email in this thread, the kernel has no 
concept of a container, it is a userspace idea and trying to generate a 
meaningful value in the kernel is a mistake in my opinion.  My current opinion 
is that we allow userspace to set a container ID token as it sees fit and the 
kernel will just use the value provided by userspace.

-- 
paul moore
security @ redhat

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ