From: Richard Guy Briggs <hidden> Date: 2014-08-21 01:10:21
The purpose is to track namespace instances in use by logged processes from the
perspective of init_*_ns by assigning each a per-kernel, per-boot serial
number.
1/8 defines a function to generate them and assigns them.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to change
reserved and is not necessarily unique if there is more than one proc fs). It
could be argued that the inode numbers have now become a defacto interface and
can't change now, but I'm proposing this approach to see if this helps address
some of the objections to the earlier patchset.
2/8 adds access functions to get to the serial numbers in a similar way to
inode access for namespace proc operations.
3/8 implements, as suggested by Serge Hallyn, making these serial numbers
available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose "snum"
instead of "seq" for consistency with inum and there are a number of other uses
of "seq" in the namespace code.
4/8 Document proc's ns entries structure in Documentation/filesystems/proc.txt
5/8 exposes proc's ns entries structure which lists a number of useful
operations per namespace type for other subsystems to use.
6/8 provides an example of usage for audit_log_task_info() which is used by
syscall audits, among others. audit_log_task() and audit_common_recv_message()
would be other potential use cases.
Proposed output format:
This differs slightly from Aristeu's patch because of the label conflict with
"pid=" due to including it in existing records rather than it being a seperate
record. It has now returned to being a seperate record. The serial numbers
are printed in hex.
type=NS_INFO msg=audit(1408577535.306:82): netns=8 utsns=2 ipcns=1 pidns=4 userns=3 mntns=5
7/8 tracks the creation and deletion of of namespaces, listing the type of
namespace instance, related namespace id if there is one and the newly minted
serial number.
Proposed output format for initial namespace creation:
type=AUDIT_NS_INIT_UTS msg=audit(1408577534.868:5): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel old_utsns=0 utsns=2 res=1
type=AUDIT_NS_INIT_USER msg=audit(1408577534.868:6): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel old_userns=0 userns=3 res=1
type=AUDIT_NS_INIT_PID msg=audit(1408577534.868:7): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel old_pidns=0 pidns=4 res=1
type=AUDIT_NS_INIT_MNT msg=audit(1408577534.868:8): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel old_mntns=0 mntns=5 res=1
type=AUDIT_NS_INIT_IPC msg=audit(1408577534.868:9): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel old_ipcns=0 ipcns=1 res=1
type=AUDIT_NS_INIT_NET msg=audit(1408577533.500:10): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel old_netns=0 netns=7 res=1
And a CLONE action would result in:
type=type=AUDIT_NS_INIT_NET msg=audit(1408577535.306:81): pid=481 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 old_netns=7 netns=8 res=1
type=type=AUDIT_NS_INIT_MNT msg=audit(1408577535.307:83): pid=481 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 old_mntns=5 mntns=9 res=1
While deleting a namespace would result in:
type=type=AUDIT_NS_DEL_MNT msg=audit(1408577552.221:85): pid=481 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 mntns=9 res=1
8/8 change audit startup from __initcall to subsys_initcall to get it started
earlier to be able to receive initial namespace log messages.
v3 -> v4:
Seperate out the NS_INFO message from the SYSCALL message.
Moved audit_log_namespace_info() out of audit_log_task_info().
Use a seperate message type per namespace type for each of INIT/DEL.
Make ns= easier to search across NS_INFO and NS_INIT/DEL_XXX msg types.
Add /proc/<pid>/ns/ documentation.
Fix dynamic initial ns logging.
v2 -> v3:
Use atomic64_t in ns_serial to simplify it.
Avoid funciton duplication in proc, keying on dentry.
Squash down audit patch to avoid rcu sleep issues.
Add tracking for creation and deletion of namespace instances.
v1 -> v2:
Avoid rollover by switching from an int to a long long.
Change rollover behaviour from simply avoiding zero to raising a BUG.
Expose serial numbers in /proc/<pid>/ns/*_snum.
Expose ns_entries and use it in audit.
Notes:
As for CAP_AUDIT_READ, a patchset has been accepted upstream to check
capabilities of userspace processes that try to join netlink broadcast groups.
This set does not try to solve the non-init namespace audit messages and
auditd problem yet. That will come later, likely with additional auditd
instances running in another namespace with a limited ability to influence the
master auditd. I echo Eric B's idea that messages destined for different
namespaces would have to be tailored for that namespace with references that
make sense (such as the right pid number reported to that pid namespace, and
not leaking info about parents or peers).
Questions:
Is there a way to link serial numbers of namespaces involved in migration of a
container to another kernel? It sounds like what is needed is a part of a
mangement application that is able to pull the audit records from constituent
hosts to build an audit trail of a container.
What additional events should list this information?
Does this present any problematic information leaks? Only CAP_AUDIT_CONTROL
(and now CAP_AUDIT_READ) in init_user_ns can get to this information in
the init namespace at the moment from audit. *However*, the addition of the
proc/<pid>/ns/*_snum does make it available to other processes now.
Richard Guy Briggs (8):
namespaces: assign each namespace instance a serial number
namespaces: expose namespace instance serial number in proc_ns_operations
namespaces: expose ns instance serial numbers in proc
Documentation: add a section for /proc/<pid>/ns/
namespaces: expose ns_entries
audit: log namespace serial numbers
audit: log creation and deletion of namespace instances
audit: initialize at subsystem time rather than device time
Documentation/filesystems/proc.txt | 16 +++++++
fs/mount.h | 1 +
fs/namespace.c | 20 +++++++++
fs/proc/namespaces.c | 35 ++++++++++++----
include/linux/audit.h | 15 +++++++
include/linux/ipc_namespace.h | 1 +
include/linux/nsproxy.h | 8 ++++
include/linux/pid_namespace.h | 1 +
include/linux/proc_ns.h | 2 +
include/linux/user_namespace.h | 1 +
include/linux/utsname.h | 1 +
include/net/net_namespace.h | 1 +
include/uapi/linux/audit.h | 13 ++++++
init/version.c | 1 +
ipc/msgutil.c | 1 +
ipc/namespace.c | 20 +++++++++
kernel/audit.c | 78 +++++++++++++++++++++++++++++++++++-
kernel/auditsc.c | 2 +
kernel/nsproxy.c | 17 ++++++++
kernel/pid.c | 1 +
kernel/pid_namespace.c | 19 +++++++++
kernel/user.c | 1 +
kernel/user_namespace.c | 20 +++++++++
kernel/utsname.c | 21 ++++++++++
net/core/net_namespace.c | 27 ++++++++++++-
security/integrity/ima/ima_api.c | 2 +
26 files changed, 314 insertions(+), 11 deletions(-)
From: Richard Guy Briggs <hidden> Date: 2014-08-21 01:10:39
Expose the namespace instance serial number for each namespace type in the proc
namespace operations structure to make it available for the proc filesystem.
Signed-off-by: Richard Guy Briggs <redacted>
---
fs/namespace.c | 7 +++++++
include/linux/proc_ns.h | 1 +
ipc/namespace.c | 8 ++++++++
kernel/pid_namespace.c | 7 +++++++
kernel/user_namespace.c | 7 +++++++
kernel/utsname.c | 8 ++++++++
net/core/net_namespace.c | 7 +++++++
7 files changed, 45 insertions(+), 0 deletions(-)
From: Richard Guy Briggs <hidden> Date: 2014-08-21 01:10:42
Expose the namespace instace serial numbers in the proc filesystem at
/proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.
"snum" was chosen instead of "seq" for consistency with inum and there are a
number of other uses of "seq" in the namespace code.
Suggested-by: Serge E. Hallyn <redacted>
Signed-off-by: Richard Guy Briggs <redacted>
---
fs/proc/namespaces.c | 33 +++++++++++++++++++++++++--------
1 files changed, 25 insertions(+), 8 deletions(-)
@@ -42,6 +42,7 @@ Table of Contents 3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm 3.7 /proc/<pid>/task/<tid>/children - Information about task children 3.8 /proc/<pid>/fdinfo/<fd> - Information about opened file+ 3.9 /proc/<pid>/ns/<ns>{,_snum} - Information about process namespaces 4 Configuring procfs 4.1 Mount options
@@ -1744,6 +1745,21 @@ pair provide additional information particular to the objects they represent. optional and may be omitted if no marks created yet.+3.9 /proc/<pid>/ns/<nstype>{,_snum} - Information about process namespaces+--------------------------------------------------------------------------+These files provides information about the namespaces within which the process+is contained. The files named only with the namespace type <nstype> contain a+link that lists the containing namespace' inode number in its proc filesystem.+The files with suffix _snum contain a link that lists the containing+namespace' instance serial number, unique per kernel since boot. The+namespace types are self-describing.++The output format of the inode links is:+ <nstype>:[<inode_number>]+The output format of the serial number links is:+ <nstype>_snum:[<serial_number>]++ ------------------------------------------------------------------------------ Configuring procfs ------------------------------------------------------------------------------
From: Richard Guy Briggs <hidden> Date: 2014-08-21 01:10:45
Expose ns_entries so subsystems other than proc can use this set of namespace
operations.
Signed-off-by: Richard Guy Briggs <redacted>
---
fs/proc/namespaces.c | 2 +-
include/linux/proc_ns.h | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
From: Richard Guy Briggs <hidden> Date: 2014-08-21 01:10:46
Log the namespace serial numbers of a task in a new record type (1329) (usually
accompanies audit_log_task_info() type=SYSCALL record) which is used by syscall
audits, among others..
Idea first presented:
https://www.redhat.com/archives/linux-audit/2013-March/msg00020.html
Typical output format would look something like:
type=NS_INFO msg=audit(1408577535.306:82): netns=8 utsns=2 ipcns=1 pidns=4 userns=3 mntns=5
The serial numbers are printed in hex.
Suggested-by: Aristeu Rozanski <redacted>
Signed-off-by: Richard Guy Briggs <redacted>
Acked-by: Serge Hallyn <redacted>
---
include/linux/audit.h | 7 +++++++
include/uapi/linux/audit.h | 1 +
kernel/audit.c | 29 +++++++++++++++++++++++++++++
kernel/auditsc.c | 2 ++
security/integrity/ima/ima_api.c | 2 ++
5 files changed, 41 insertions(+), 0 deletions(-)
From: Richard Guy Briggs <hidden> Date: 2014-08-21 01:10:47
Log the creation and deletion of namespace instances in all 6 types of
namespaces.
Twelve new audit message types have been introduced:
AUDIT_NS_INIT_MNT 1330 /* Record mount namespace instance creation */
AUDIT_NS_INIT_UTS 1331 /* Record UTS namespace instance creation */
AUDIT_NS_INIT_IPC 1332 /* Record IPC namespace instance creation */
AUDIT_NS_INIT_USER 1333 /* Record USER namespace instance creation */
AUDIT_NS_INIT_PID 1334 /* Record PID namespace instance creation */
AUDIT_NS_INIT_NET 1335 /* Record NET namespace instance creation */
AUDIT_NS_DEL_MNT 1336 /* Record mount namespace instance deletion */
AUDIT_NS_DEL_UTS 1337 /* Record UTS namespace instance deletion */
AUDIT_NS_DEL_IPC 1338 /* Record IPC namespace instance deletion */
AUDIT_NS_DEL_USER 1339 /* Record USER namespace instance deletion */
AUDIT_NS_DEL_PID 1340 /* Record PID namespace instance deletion */
AUDIT_NS_DEL_NET 1341 /* Record NET namespace instance deletion */
As suggested by Eric Paris, there are 12 message types, one for each of
creation and deletion, one for each type of namespace so that text searches are
easier in conjunction with the AUDIT_NS_INFO message type, being able to search
for all records such as "netns=7 " and to avoid fields disappearing per message
type to make ausearch more efficient.
A typical startup would look roughly like:
type=AUDIT_NS_INIT_UTS msg=audit(1408577534.868:5): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel old_utsns=0 utsns=2 res=1
type=AUDIT_NS_INIT_USER msg=audit(1408577534.868:6): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel old_userns=0 userns=3 res=1
type=AUDIT_NS_INIT_PID msg=audit(1408577534.868:7): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel old_pidns=0 pidns=4 res=1
type=AUDIT_NS_INIT_MNT msg=audit(1408577534.868:8): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel old_mntns=0 mntns=5 res=1
type=AUDIT_NS_INIT_IPC msg=audit(1408577534.868:9): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel old_ipcns=0 ipcns=1 res=1
type=AUDIT_NS_INIT_NET msg=audit(1408577533.500:10): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel old_netns=0 netns=7 res=1
And a CLONE action would result in:
type=type=AUDIT_NS_INIT_NET msg=audit(1408577535.306:81): pid=481 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 old_netns=7 netns=8 res=1
type=type=AUDIT_NS_INIT_MNT msg=audit(1408577535.307:83): pid=481 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 old_mntns=5 mntns=9 res=1
While deleting a namespace would result in:
type=type=AUDIT_NS_DEL_MNT msg=audit(1408577552.221:85): pid=481 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 mntns=9 res=1
If non-zero, old_snum lists the namespace from which it was cloned.
Signed-off-by: Richard Guy Briggs <redacted>
---
fs/namespace.c | 12 +++++++++++
include/linux/audit.h | 8 +++++++
include/uapi/linux/audit.h | 12 +++++++++++
ipc/namespace.c | 10 +++++++++
kernel/audit.c | 47 ++++++++++++++++++++++++++++++++++++++++++++
kernel/pid_namespace.c | 10 +++++++++
kernel/user_namespace.c | 11 ++++++++++
kernel/utsname.c | 11 ++++++++++
net/core/net_namespace.c | 12 +++++++++++
9 files changed, 133 insertions(+), 0 deletions(-)
@@ -2519,6 +2521,7 @@ struct mnt_namespace *copy_mnt_ns(unsigned long flags, struct mnt_namespace *ns,new_ns=alloc_mnt_ns(user_ns);if(IS_ERR(new_ns))returnnew_ns;+audit_log_ns_init(AUDIT_NS_INIT_MNT,ns->serial_num,new_ns->serial_num);namespace_lock();/* First pass: copy the tree topology */
@@ -2831,6 +2834,15 @@ static void __init init_mount_tree(void)set_fs_root(current->fs,&root);}+/* log the serial number of init mnt namespace after audit service starts */+staticint__initmnt_ns_init_log(void)+{+structmnt_namespace*init_mnt_ns=init_task.nsproxy->mnt_ns;+audit_log_ns_init(AUDIT_NS_INIT_MNT,0,init_mnt_ns->serial_num);+return0;+}+late_initcall(mnt_ns_init_log);+void__initmnt_init(void){unsignedu;
@@ -93,6 +94,8 @@ int create_user_ns(struct cred *new)}ns->serial_num=ns_serial();+audit_log_ns_init(AUDIT_NS_INIT_USER,parent_ns->serial_num,+ns->serial_num);atomic_set(&ns->count,1);/* Leave the new->user_ns reference with the new user namespace. */
@@ -253,6 +254,8 @@ struct net *copy_net_ns(unsigned long flags,mutex_lock(&net_mutex);rv=setup_net(net,user_ns);if(rv==0){+audit_log_ns_init(AUDIT_NS_INIT_NET,old_net->serial_num,+net->serial_num);rtnl_lock();list_add_tail_rcu(&net->list,&net_namespace_list);rtnl_unlock();
@@ -395,6 +398,7 @@ static __net_init int net_ns_net_init(struct net *net)static__net_exitvoidnet_ns_net_exit(structnet*net){+audit_log_ns_del(AUDIT_NS_DEL_NET,net->serial_num);proc_free_inum(net->proc_inum);}
@@ -441,6 +445,14 @@ static int __init net_ns_init(void)pure_initcall(net_ns_init);+/* log the serial number of init_net namespace after audit service starts */+staticint__initnet_ns_init_log(void)+{+audit_log_ns_init(AUDIT_NS_INIT_NET,0,init_net.serial_num);+return0;+}+late_initcall(net_ns_init_log);+#ifdef CONFIG_NET_NSstaticint__register_pernet_operations(structlist_head*list,structpernet_operations*ops)
From: Richard Guy Briggs <hidden> Date: 2014-08-21 01:10:48
The audit subsystem should be initialized a bit earlier so that it is in place
in time for initial namespace serial number logging.
---
kernel/audit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
@@ -1186,7 +1186,7 @@ static int __init audit_init(void)return0;}-__initcall(audit_init);+subsys_initcall(audit_init);/* Process kernel command-line parameter at boot time. audit=0 or audit=1. */staticint__initaudit_enable(char*str)
From: Richard Guy Briggs <hidden> Date: 2014-08-21 01:10:49
Generate and assign a serial number per namespace instance since boot.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to change
reserved and is not necessarily unique if there is more than one proc fs) to
uniquely identify it per kernel boot.
Signed-off-by: Richard Guy Briggs <redacted>
---
fs/mount.h | 1 +
fs/namespace.c | 1 +
include/linux/ipc_namespace.h | 1 +
include/linux/nsproxy.h | 8 ++++++++
include/linux/pid_namespace.h | 1 +
include/linux/user_namespace.h | 1 +
include/linux/utsname.h | 1 +
include/net/net_namespace.h | 1 +
init/version.c | 1 +
ipc/msgutil.c | 1 +
ipc/namespace.c | 2 ++
kernel/nsproxy.c | 17 +++++++++++++++++
kernel/pid.c | 1 +
kernel/pid_namespace.c | 2 ++
kernel/user.c | 1 +
kernel/user_namespace.c | 2 ++
kernel/utsname.c | 2 ++
net/core/net_namespace.c | 8 +++++++-
18 files changed, 51 insertions(+), 1 deletions(-)
@@ -43,6 +43,7 @@ struct pid_namespace {inthide_pid;intreboot;/* group exit code if this pidns was rebooted */unsignedintproc_inum;+longlongserial_num;};externstructpid_namespaceinit_pid_ns;
@@ -92,6 +92,8 @@ int create_user_ns(struct cred *new)returnret;}+ns->serial_num=ns_serial();+atomic_set(&ns->count,1);/* Leave the new->user_ns reference with the new user namespace. */ns->parent=parent_ns;
Hi Richard,
On Wed, Aug 20, 2014 at 09:09:33PM -0400, Richard Guy Briggs wrote:
Is there a way to link serial numbers of namespaces involved in migration of a
container to another kernel? It sounds like what is needed is a part of a
mangement application that is able to pull the audit records from constituent
hosts to build an audit trail of a container.
since you're introducing a brand new serial number to make it unique
across different procfs mounts, why not instead of a simple counter,
use the hash output of say, $hostname-$creation_time-$random? Or perhaps
get a short hash of the hostname (generated once whenever hostname is
set) and append the serial number you're implementing? It'd be way less human
readable than your current proposal but it'd be unique "globally" (as long you
don't have machines with the same hostname migrating containers between them),
allowing the migrated namespaces to retain their unique identification across
audit logs. It'd of course be way more costly than just using an atomic counter,
but could be useful to anything that needs to refer to a namespace and could be
migrated to another machine.
What you think? Sounds too crazy? :)
--
Aristeu
From: Andy Lutomirski <luto@amacapital.net> Date: 2014-08-21 21:13:52
On Aug 20, 2014 8:12 PM, "Richard Guy Briggs" [off-list ref] wrote:
Expose the namespace instace serial numbers in the proc filesystem at
/proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.
What's the use case?
I understand the utility of giving unique numbers to the audit code,
but I don't think this part is necessary for that, and I'd like to
understand what else will use this before committing to a duplicative
API like this.
Note that this API is thoroughly incompatible with CRIU. If we do
this, someone will ask for a namespace number namespace, and that way
lies madness.
--Andy
quoted hunk
"snum" was chosen instead of "seq" for consistency with inum and there are a
number of other uses of "seq" in the namespace code.
Suggested-by: Serge E. Hallyn <redacted>
Signed-off-by: Richard Guy Briggs <redacted>
---
fs/proc/namespaces.c | 33 +++++++++++++++++++++++++--------
1 files changed, 25 insertions(+), 8 deletions(-)
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Andy Lutomirski <luto@amacapital.net> Date: 2014-08-21 21:22:54
On Aug 20, 2014 8:12 PM, "Richard Guy Briggs" [off-list ref] wrote:
quoted hunk
Generate and assign a serial number per namespace instance since boot.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to change
reserved and is not necessarily unique if there is more than one proc fs) to
uniquely identify it per kernel boot.
Signed-off-by: Richard Guy Briggs <redacted>
---
fs/mount.h | 1 +
fs/namespace.c | 1 +
include/linux/ipc_namespace.h | 1 +
include/linux/nsproxy.h | 8 ++++++++
include/linux/pid_namespace.h | 1 +
include/linux/user_namespace.h | 1 +
include/linux/utsname.h | 1 +
include/net/net_namespace.h | 1 +
init/version.c | 1 +
ipc/msgutil.c | 1 +
ipc/namespace.c | 2 ++
kernel/nsproxy.c | 17 +++++++++++++++++
kernel/pid.c | 1 +
kernel/pid_namespace.c | 2 ++
kernel/user.c | 1 +
kernel/user_namespace.c | 2 ++
kernel/utsname.c | 2 ++
net/core/net_namespace.c | 8 +++++++-
18 files changed, 51 insertions(+), 1 deletions(-)
Please add an extra value here for the first dynamic value...
+/**
+ * ns_serial - compute a serial number for the namespace
+ *
+ * Compute a serial number for the namespace to uniquely identify it in
+ * audit records.
+ */
+long long ns_serial(void)
+{
+ static atomic64_t serial = ATOMIC_INIT(4); /* reserved for IPC, UTS, user, PID */
...and use it here.
Also, does this work on all architectures?
--Andy
From: Richard Guy Briggs <hidden> Date: 2014-08-21 21:28:34
On 14/08/21, Andy Lutomirski wrote:
On Aug 20, 2014 8:12 PM, "Richard Guy Briggs" [off-list ref] wrote:
quoted
Generate and assign a serial number per namespace instance since boot.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to change
reserved and is not necessarily unique if there is more than one proc fs) to
uniquely identify it per kernel boot.
Signed-off-by: Richard Guy Briggs <redacted>
---
fs/mount.h | 1 +
fs/namespace.c | 1 +
include/linux/ipc_namespace.h | 1 +
include/linux/nsproxy.h | 8 ++++++++
include/linux/pid_namespace.h | 1 +
include/linux/user_namespace.h | 1 +
include/linux/utsname.h | 1 +
include/net/net_namespace.h | 1 +
init/version.c | 1 +
ipc/msgutil.c | 1 +
ipc/namespace.c | 2 ++
kernel/nsproxy.c | 17 +++++++++++++++++
kernel/pid.c | 1 +
kernel/pid_namespace.c | 2 ++
kernel/user.c | 1 +
kernel/user_namespace.c | 2 ++
kernel/utsname.c | 2 ++
net/core/net_namespace.c | 8 +++++++-
18 files changed, 51 insertions(+), 1 deletions(-)
Please add an extra value here for the first dynamic value...
quoted
+/**
+ * ns_serial - compute a serial number for the namespace
+ *
+ * Compute a serial number for the namespace to uniquely identify it in
+ * audit records.
+ */
+long long ns_serial(void)
+{
+ static atomic64_t serial = ATOMIC_INIT(4); /* reserved for IPC, UTS, user, PID */
...and use it here.
Yup, good idea. Thanks.
Also, does this work on all architectures?
I only know for certain x86_64. There is discussion elsewhere about
changing ns_serial from returning a long long to returning a u64. That
should help. I can run standard compile and boot tests on several
others, but won't be able to check output.
--Andy
- RGB
--
Richard Guy Briggs [off-list ref]
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
From: Andy Lutomirski <luto@amacapital.net> Date: 2014-08-21 21:30:48
On Thu, Aug 21, 2014 at 2:28 PM, Richard Guy Briggs [off-list ref] wrote:
On 14/08/21, Andy Lutomirski wrote:
quoted
On Aug 20, 2014 8:12 PM, "Richard Guy Briggs" [off-list ref] wrote:
quoted
Generate and assign a serial number per namespace instance since boot.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to change
reserved and is not necessarily unique if there is more than one proc fs) to
uniquely identify it per kernel boot.
Signed-off-by: Richard Guy Briggs <redacted>
---
fs/mount.h | 1 +
fs/namespace.c | 1 +
include/linux/ipc_namespace.h | 1 +
include/linux/nsproxy.h | 8 ++++++++
include/linux/pid_namespace.h | 1 +
include/linux/user_namespace.h | 1 +
include/linux/utsname.h | 1 +
include/net/net_namespace.h | 1 +
init/version.c | 1 +
ipc/msgutil.c | 1 +
ipc/namespace.c | 2 ++
kernel/nsproxy.c | 17 +++++++++++++++++
kernel/pid.c | 1 +
kernel/pid_namespace.c | 2 ++
kernel/user.c | 1 +
kernel/user_namespace.c | 2 ++
kernel/utsname.c | 2 ++
net/core/net_namespace.c | 8 +++++++-
18 files changed, 51 insertions(+), 1 deletions(-)
Please add an extra value here for the first dynamic value...
quoted
+/**
+ * ns_serial - compute a serial number for the namespace
+ *
+ * Compute a serial number for the namespace to uniquely identify it in
+ * audit records.
+ */
+long long ns_serial(void)
+{
+ static atomic64_t serial = ATOMIC_INIT(4); /* reserved for IPC, UTS, user, PID */
...and use it here.
Yup, good idea. Thanks.
quoted
Also, does this work on all architectures?
I only know for certain x86_64. There is discussion elsewhere about
changing ns_serial from returning a long long to returning a u64. That
should help. I can run standard compile and boot tests on several
others, but won't be able to check output.
I was thinking of atomic64. I guess there's a generic implementation
that works everywhere, if somewhat slowly.
--Andy
From: Richard Guy Briggs <hidden> Date: 2014-08-21 22:15:16
On 14/08/21, Andy Lutomirski wrote:
On Thu, Aug 21, 2014 at 2:28 PM, Richard Guy Briggs [off-list ref] wrote:
quoted
On 14/08/21, Andy Lutomirski wrote:
quoted
On Aug 20, 2014 8:12 PM, "Richard Guy Briggs" [off-list ref] wrote:
quoted
Generate and assign a serial number per namespace instance since boot.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to change
reserved and is not necessarily unique if there is more than one proc fs) to
uniquely identify it per kernel boot.
Signed-off-by: Richard Guy Briggs <redacted>
---
fs/mount.h | 1 +
fs/namespace.c | 1 +
include/linux/ipc_namespace.h | 1 +
include/linux/nsproxy.h | 8 ++++++++
include/linux/pid_namespace.h | 1 +
include/linux/user_namespace.h | 1 +
include/linux/utsname.h | 1 +
include/net/net_namespace.h | 1 +
init/version.c | 1 +
ipc/msgutil.c | 1 +
ipc/namespace.c | 2 ++
kernel/nsproxy.c | 17 +++++++++++++++++
kernel/pid.c | 1 +
kernel/pid_namespace.c | 2 ++
kernel/user.c | 1 +
kernel/user_namespace.c | 2 ++
kernel/utsname.c | 2 ++
net/core/net_namespace.c | 8 +++++++-
18 files changed, 51 insertions(+), 1 deletions(-)
Please add an extra value here for the first dynamic value...
quoted
+/**
+ * ns_serial - compute a serial number for the namespace
+ *
+ * Compute a serial number for the namespace to uniquely identify it in
+ * audit records.
+ */
+long long ns_serial(void)
+{
+ static atomic64_t serial = ATOMIC_INIT(4); /* reserved for IPC, UTS, user, PID */
...and use it here.
Yup, good idea. Thanks.
quoted
Also, does this work on all architectures?
I only know for certain x86_64. There is discussion elsewhere about
changing ns_serial from returning a long long to returning a u64. That
should help. I can run standard compile and boot tests on several
others, but won't be able to check output.
I was thinking of atomic64. I guess there's a generic implementation
that works everywhere, if somewhat slowly.
Yup.
From include/linux/types.h:
#ifdef CONFIG_64BIT
typedef struct {
long counter;
} atomic64_t;
#endif
From include/asm-generic/atomic64.h:
typedef struct {
long long counter;
} atomic64_t;
and for non-x86, there is lib/atomic64.c:
atomic64_add_return()
which is in C while the x86_64 version is in ASM.
--Andy
- RGB
--
Richard Guy Briggs [off-list ref]
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
From: Richard Guy Briggs <hidden> Date: 2014-08-21 22:33:02
On 14/08/21, Aristeu Rozanski wrote:
Hi Richard,
Hi Aris,
On Wed, Aug 20, 2014 at 09:09:33PM -0400, Richard Guy Briggs wrote:
quoted
Is there a way to link serial numbers of namespaces involved in migration of a
container to another kernel? It sounds like what is needed is a part of a
mangement application that is able to pull the audit records from constituent
hosts to build an audit trail of a container.
since you're introducing a brand new serial number to make it unique
across different procfs mounts, why not instead of a simple counter,
use the hash output of say, $hostname-$creation_time-$random?
I had thought of this earlier on, but I could see many VMs started up
from an identical image, making the resulting hash possibly identical.
Besides, hostname isn't known yet when we are creating initial
namespaces.
Or perhaps
get a short hash of the hostname (generated once whenever hostname is
set) and append the serial number you're implementing? It'd be way less human
readable than your current proposal but it'd be unique "globally" (as long you
don't have machines with the same hostname migrating containers between them),
allowing the migrated namespaces to retain their unique identification across
audit logs. It'd of course be way more costly than just using an atomic counter,
but could be useful to anything that needs to refer to a namespace and could be
migrated to another machine.
This also means that any namespace that is migrated would have to be
recreated on another host and inject an existing ID into it rather than
have the host creating it generate that ID. Some namespaces are peers
that take the kernel default, while others are hierarchical and inherit
from their creating namespaces.
It was much easier at my layer to punt that management to a higher
layer that already knew about the other hosts in play and to manage that
information as it saw fit.
What you think? Sounds too crazy? :)
Yup. I was hoping there would be some kind of unique identifier per
running kernel, including CPU_ID (which may not exist or may be shut
off), RTC boot value (which may be identical for VMs), or initial random
state (which could be identical for VMs).
Aristeu
- RGB
--
Richard Guy Briggs [off-list ref]
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
From: Richard Guy Briggs <hidden> Date: 2014-08-22 01:58:14
On 14/08/21, Andy Lutomirski wrote:
On Aug 20, 2014 8:12 PM, "Richard Guy Briggs" [off-list ref] wrote:
quoted
Expose the namespace instace serial numbers in the proc filesystem at
/proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.
What's the use case?
I understand the utility of giving unique numbers to the audit code,
but I don't think this part is necessary for that, and I'd like to
understand what else will use this before committing to a duplicative
API like this.
How does a container manager get those numbers? It could provoke a task
to cause an audit event that emits a NS_INFO message, or it could run a
task in that container to report its namespace serial numbers directly
from its /proc mount.
The discussion in this thread touches on the use cases:
https://lkml.org/lkml/2014/4/22/662
Note that this API is thoroughly incompatible with CRIU. If we do
this, someone will ask for a namespace number namespace, and that way
lies madness.
I had a very brief look at CRIU, but not enough to understand the issue.
Others have hinted at this problem.
Do you have a suggestion of a different approach that would be
compatible with CRIU?
I'd originally considered some sort of UUID that would be globally
unique, but that would be very hard to devise or guarantee, and besides,
namespaces aren't only used by containers and could be shared in other
ways. Tracking the usage and migration of namespaces should be the task
of an upper layer.
--Andy
quoted
"snum" was chosen instead of "seq" for consistency with inum and there are a
number of other uses of "seq" in the namespace code.
Suggested-by: Serge E. Hallyn <redacted>
Signed-off-by: Richard Guy Briggs <redacted>
---
fs/proc/namespaces.c | 33 +++++++++++++++++++++++++--------
1 files changed, 25 insertions(+), 8 deletions(-)
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- RGB
--
Richard Guy Briggs [off-list ref]
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
From: Andy Lutomirski <luto@amacapital.net> Date: 2014-08-24 17:52:47
On Thu, Aug 21, 2014 at 6:58 PM, Richard Guy Briggs [off-list ref] wrote:
On 14/08/21, Andy Lutomirski wrote:
quoted
On Aug 20, 2014 8:12 PM, "Richard Guy Briggs" [off-list ref] wrote:
quoted
Expose the namespace instace serial numbers in the proc filesystem at
/proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.
What's the use case?
I understand the utility of giving unique numbers to the audit code,
but I don't think this part is necessary for that, and I'd like to
understand what else will use this before committing to a duplicative
API like this.
How does a container manager get those numbers? It could provoke a task
to cause an audit event that emits a NS_INFO message, or it could run a
task in that container to report its namespace serial numbers directly
from its /proc mount.
Why does a container manager need them? Is there any reason that
keeping them entirely contained within the audit system would be a
problem?
Note that this API is thoroughly incompatible with CRIU. If we do
this, someone will ask for a namespace number namespace, and that way
lies madness.
I had a very brief look at CRIU, but not enough to understand the issue.
Others have hinted at this problem.
Do you have a suggestion of a different approach that would be
compatible with CRIU?
I'd originally considered some sort of UUID that would be globally
unique, but that would be very hard to devise or guarantee, and besides,
namespaces aren't only used by containers and could be shared in other
ways. Tracking the usage and migration of namespaces should be the task
of an upper layer.
CRIU wants to save the complete state of a namespace and then restore
it. For that to work, any information exposed to things in the
namespace *cannot* be globally unique or unique per boot, since CRIU
needs to arrange for that information to match whatever it was when
CRIU saved it.
Also, I think that code running in a namespace has no business even
knowing a unique identity of that namespace from the perspective of
the host.
Here's a specific use case for *not* exposing this: Tor. Ideally, Tor
clients would run in a namespace that does not know about any global
identity. That means no IP addresses, but it also means no global
namespace serial numbers.
--Andy
From: Richard Guy Briggs <hidden> Date: 2014-08-24 20:28:39
On 14/08/24, Andy Lutomirski wrote:
On Thu, Aug 21, 2014 at 6:58 PM, Richard Guy Briggs [off-list ref] wrote:
quoted
On 14/08/21, Andy Lutomirski wrote:
quoted
On Aug 20, 2014 8:12 PM, "Richard Guy Briggs" [off-list ref] wrote:
quoted
Expose the namespace instace serial numbers in the proc filesystem at
/proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.
What's the use case?
I understand the utility of giving unique numbers to the audit code,
but I don't think this part is necessary for that, and I'd like to
understand what else will use this before committing to a duplicative
API like this.
How does a container manager get those numbers? It could provoke a task
to cause an audit event that emits a NS_INFO message, or it could run a
task in that container to report its namespace serial numbers directly
from its /proc mount.
Why does a container manager need them? Is there any reason that
keeping them entirely contained within the audit system would be a
problem?
The audit system is currently per-kernel. If a container is migrated
from one kernel to another, the first audit system is no longer able to
monitor or care about it. It is the container manager's scope that has
the capability to monitor and care about it.
This might be a good argument to augment the audit system as we
currently know it to be able to do this across kernels, but that isn't
currently the case.
Note that this API is thoroughly incompatible with CRIU. If we do
this, someone will ask for a namespace number namespace, and that way
lies madness.
I had a very brief look at CRIU, but not enough to understand the issue.
Others have hinted at this problem.
Do you have a suggestion of a different approach that would be
compatible with CRIU?
I'd originally considered some sort of UUID that would be globally
unique, but that would be very hard to devise or guarantee, and besides,
namespaces aren't only used by containers and could be shared in other
ways. Tracking the usage and migration of namespaces should be the task
of an upper layer.
CRIU wants to save the complete state of a namespace and then restore
it. For that to work, any information exposed to things in the
namespace *cannot* be globally unique or unique per boot, since CRIU
needs to arrange for that information to match whatever it was when
CRIU saved it.
So are you agreeing with Eric Biederman's idea that its proc inode
number should be initially assigned serially, but reserve the right to
be settable on a restore of a namespace from another host? What if that
inode number collides with an existing one?
Does CRIU have no lattitude at all to be able to track a new namespace
ID?
Also, I think that code running in a namespace has no business even
knowing a unique identity of that namespace from the perspective of
the host.
Too late. There is already the namespace proc inode numbers. That
number is almost completely meaningless to the code running inside the
container/namespace.
Here's a specific use case for *not* exposing this: Tor. Ideally, Tor
clients would run in a namespace that does not know about any global
identity. That means no IP addresses, but it also means no global
namespace serial numbers.
Well, it already has an IP address (which might be masqueraded by the
host or another upstream router) and a namespace inode number.
I'm not aware of support for anonymous namespaces, let along anonymous
containers yet.
--Andy
- RGB
--
Richard Guy Briggs [off-list ref]
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
From: Nicolas Dichtel <hidden> Date: 2014-08-25 13:30:53
Le 24/08/2014 19:52, Andy Lutomirski a écrit :
On Thu, Aug 21, 2014 at 6:58 PM, Richard Guy Briggs [off-list ref] wrote:
quoted
On 14/08/21, Andy Lutomirski wrote:
quoted
On Aug 20, 2014 8:12 PM, "Richard Guy Briggs" [off-list ref] wrote:
quoted
Expose the namespace instace serial numbers in the proc filesystem at
/proc/<pid>/ns/<ns>_snum. The link text gives the serial number in hex.
What's the use case?
I understand the utility of giving unique numbers to the audit code,
but I don't think this part is necessary for that, and I'd like to
understand what else will use this before committing to a duplicative
API like this.
How does a container manager get those numbers? It could provoke a task
to cause an audit event that emits a NS_INFO message, or it could run a
task in that container to report its namespace serial numbers directly
from its /proc mount.
Why does a container manager need them? Is there any reason that
keeping them entirely contained within the audit system would be a
problem?
Note that this API is thoroughly incompatible with CRIU. If we do
this, someone will ask for a namespace number namespace, and that way
lies madness.
I had a very brief look at CRIU, but not enough to understand the issue.
Others have hinted at this problem.
Do you have a suggestion of a different approach that would be
compatible with CRIU?
I'd originally considered some sort of UUID that would be globally
unique, but that would be very hard to devise or guarantee, and besides,
namespaces aren't only used by containers and could be shared in other
ways. Tracking the usage and migration of namespaces should be the task
of an upper layer.
CRIU wants to save the complete state of a namespace and then restore
it. For that to work, any information exposed to things in the
namespace *cannot* be globally unique or unique per boot, since CRIU
needs to arrange for that information to match whatever it was when
CRIU saved it.
How are ifindex of network devices managed? These ifindexes are unique per boot,
thus can change depending on the order in which netdev are created.
These ifindexes are unique per boot and exposed to userspace ...
Also, I think that code running in a namespace has no business even
knowing a unique identity of that namespace from the perspective of
the host.
Another scenario is when you have virtual network devices across two netns. You
need to identify the peer netns to have a netlink message which is fully
interpretable by the userspace.
Regards,
Nicolas
From: Andy Lutomirski <luto@amacapital.net> Date: 2014-08-25 14:04:52
On Aug 25, 2014 6:30 AM, "Nicolas Dichtel" [off-list ref] wrote:
quoted
CRIU wants to save the complete state of a namespace and then restore
it. For that to work, any information exposed to things in the
namespace *cannot* be globally unique or unique per boot, since CRIU
needs to arrange for that information to match whatever it was when
CRIU saved it.
How are ifindex of network devices managed? These ifindexes are unique per boot,
thus can change depending on the order in which netdev are created.
These ifindexes are unique per boot and exposed to userspace ...
This does not appear to be true.
$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000
quoted
Also, I think that code running in a namespace has no business even
knowing a unique identity of that namespace from the perspective of
the host.
Another scenario is when you have virtual network devices across two netns. You
need to identify the peer netns to have a netlink message which is fully interpretable by the userspace.
Let me try again, with emphasis in the right place.
I think that *code running in a namespace* has no business even
knowing a unique identity of *that namespace* from the perspective of
the host.
In your example, if there's a veth device between netns A and netns B,
then code *in netns A* has no business knowing the identity of its
veth peer if its peer (B) is a sibling or ancestor. It also IMO has
no business knowing the identity of its own netns (A) other than as
"my netns".
If A and B are siblings, then their parent needs to know where that
veth device goes, but I think this is already the case to a sufficient
extent today.
I feel like this discussion is falling into a common trap of new API
discussions. Can one of you who wants this API please articulate,
with a reasonably precise example, what it is that you want to do, why
you can't easily do it already, and how this API helps? I currently
understand how the API creates problems, but I don't understand how it
solves any problems, and I will NAK it (and I suspect that Eric will,
too, which is pretty much fatal) unless that changes.
Thanks,
Andy
From: Nicolas Dichtel <hidden> Date: 2014-08-25 15:43:39
Le 25/08/2014 16:04, Andy Lutomirski a écrit :
On Aug 25, 2014 6:30 AM, "Nicolas Dichtel" [off-list ref] wrote:
quoted
quoted
CRIU wants to save the complete state of a namespace and then restore
it. For that to work, any information exposed to things in the
namespace *cannot* be globally unique or unique per boot, since CRIU
needs to arrange for that information to match whatever it was when
CRIU saved it.
How are ifindex of network devices managed? These ifindexes are unique per boot,
thus can change depending on the order in which netdev are created.
These ifindexes are unique per boot and exposed to userspace ...
This does not appear to be true.
$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000
I've probably misunderstood what you're trying to say. ifindexes are unique per
boot and per netns. These ifindexes depend on the interface creation order:
$ ip netns add 1
$ ip link set eth1 netns 1
$ ip netns exec 1 ip link add veth0 type veth peer name veth1
$ ip netns exec 1 ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 9a:a0:89:99:a0:3c brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group
default qlen 1000
link/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff
4: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 96:86:44:49:ce:a8 brd ff:ff:ff:ff:ff:ff
$ ip netns del 1
$ ip netns add 1
$ ip netns exec 1 ip link add veth0 type veth peer name veth1
$ ip link set eth1 netns 1
$ ip netns exec 1 ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 86:92:90:01:32:6b brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether ae:8b:d2:71:48:a2 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group
default qlen 1000
link/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff
Note: when an interface is moved to another netns, the ifindex is kept if
possible, else another ifindex is chosen.
I will dig a bit to understand how CRIU save these netns informations.
quoted
quoted
Also, I think that code running in a namespace has no business even
knowing a unique identity of that namespace from the perspective of
the host.
Another scenario is when you have virtual network devices across two netns. You
need to identify the peer netns to have a netlink message which is fully interpretable by the userspace.
Let me try again, with emphasis in the right place.
I think that *code running in a namespace* has no business even
knowing a unique identity of *that namespace* from the perspective of
the host.
In your example, if there's a veth device between netns A and netns B,
then code *in netns A* has no business knowing the identity of its
veth peer if its peer (B) is a sibling or ancestor. It also IMO has
no business knowing the identity of its own netns (A) other than as
"my netns".
I do not agree (see the example below).
If A and B are siblings, then their parent needs to know where that
veth device goes, but I think this is already the case to a sufficient
extent today.
I'm not aware of a hierarchy between netns. A daemon should be able to
got the full network configuration, even if it's started when this configuration
is already applied, ie even if it doesn't know what happen before it starts.
I feel like this discussion is falling into a common trap of new API
discussions. Can one of you who wants this API please articulate,
with a reasonably precise example, what it is that you want to do, why
you can't easily do it already, and how this API helps? I currently
understand how the API creates problems, but I don't understand how it
solves any problems, and I will NAK it (and I suspect that Eric will,
too, which is pretty much fatal) unless that changes.
What I'm trying to solve is to have full info in netlink messages sent by the
kernel, thus beeing able to identify a peer netns (and this is close from what
audit guys are trying to have). Theorically, messages sent by the kernel can be
reused as is to have the same configuration. This is not the case with x-netns
devices. Here is an example, with ip tunnels:
$ ip netns add 1
$ ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249 dev eth0
$ ip -d link ls ipip1
8: ipip1@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT
group default
link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
ipip remote 10.16.0.121 local 10.16.0.249 dev eth0 ttl inherit pmtudisc
$ ip link set ipip1 netns 1
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@tunl0: <POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN mode
DEFAULT group default
link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
ipip remote 10.16.0.121 local 10.16.0.249 dev tunl0 ttl inherit pmtudisc
Now informations got with 'ip link' are wrong and incomplete:
- the link dev is now tunl0 instead of eth0, because we only got an ifindex
from the kernel without any netns informations.
- the encapsulation addresses are not part of this netns but the user doesn't
known that (still because netns info is missing). These IPv4 addresses may
exist into this netns.
- it's not possible to create the same netdevice with these infos.
Hope it's more clear now.
Regards,
Nicolas
From: Andy Lutomirski <luto@amacapital.net> Date: 2014-08-25 16:13:55
On Mon, Aug 25, 2014 at 8:43 AM, Nicolas Dichtel
[off-list ref] wrote:
Le 25/08/2014 16:04, Andy Lutomirski a écrit :
quoted
On Aug 25, 2014 6:30 AM, "Nicolas Dichtel" [off-list ref]
wrote:
quoted
quoted
CRIU wants to save the complete state of a namespace and then restore
it. For that to work, any information exposed to things in the
namespace *cannot* be globally unique or unique per boot, since CRIU
needs to arrange for that information to match whatever it was when
CRIU saved it.
How are ifindex of network devices managed? These ifindexes are unique
per boot,
thus can change depending on the order in which netdev are created.
These ifindexes are unique per boot and exposed to userspace ...
This does not appear to be true.
$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000
I've probably misunderstood what you're trying to say. ifindexes are unique
per
boot and per netns.
I think we both misunderstood each other. The ifindexes are unique
*per netns*, which means that, if you're unprivileged in a netns,
global information doesn't leak to you. I think this is good.
quoted
Let me try again, with emphasis in the right place.
I think that *code running in a namespace* has no business even
knowing a unique identity of *that namespace* from the perspective of
the host.
In your example, if there's a veth device between netns A and netns B,
then code *in netns A* has no business knowing the identity of its
veth peer if its peer (B) is a sibling or ancestor. It also IMO has
no business knowing the identity of its own netns (A) other than as
"my netns".
I do not agree (see the example below).
quoted
If A and B are siblings, then their parent needs to know where that
veth device goes, but I think this is already the case to a sufficient
extent today.
I'm not aware of a hierarchy between netns. A daemon should be able to
got the full network configuration, even if it's started when this
configuration
is already applied, ie even if it doesn't know what happen before it starts.
I don't know exactly which namespaces have an explicit hierarchy, but
there is certainly a hierarchy of *user* namespaces, and network
namespaces live in user namespaces, so they at least have somewhat of
a hierarchy.
quoted
I feel like this discussion is falling into a common trap of new API
discussions. Can one of you who wants this API please articulate,
with a reasonably precise example, what it is that you want to do, why
you can't easily do it already, and how this API helps? I currently
understand how the API creates problems, but I don't understand how it
solves any problems, and I will NAK it (and I suspect that Eric will,
too, which is pretty much fatal) unless that changes.
What I'm trying to solve is to have full info in netlink messages sent by
the
kernel, thus beeing able to identify a peer netns (and this is close from
what
audit guys are trying to have). Theorically, messages sent by the kernel can
be
reused as is to have the same configuration. This is not the case with
x-netns
devices. Here is an example, with ip tunnels:
$ ip netns add 1
$ ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249 dev eth0
$ ip -d link ls ipip1
8: ipip1@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode
DEFAULT group default
link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
ipip remote 10.16.0.121 local 10.16.0.249 dev eth0 ttl inherit pmtudisc
$ ip link set ipip1 netns 1
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@tunl0: <POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
mode DEFAULT group default
link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
ipip remote 10.16.0.121 local 10.16.0.249 dev tunl0 ttl inherit pmtudisc
Now informations got with 'ip link' are wrong and incomplete:
- the link dev is now tunl0 instead of eth0, because we only got an ifindex
from the kernel without any netns informations.
- the encapsulation addresses are not part of this netns but the user
doesn't
known that (still because netns info is missing). These IPv4 addresses
may
exist into this netns.
- it's not possible to create the same netdevice with these infos.
Aha. That's a genuine problem.
Perhaps we need a concept of which netnses should be able to see each other.
I think I would be okay with a somewhat different outcome from your example:
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@[unknown device in another namespace]:
<POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
I think this outcome is mandatory if netns 1 lives in a subsidiary
user namespace.
Certainly, if you do the 'ip link' in the original namespace, I agree
that this should work.
For most namespace types, this all works transparently, since
everything has an real identity all the way up the hierarchy. Network
namespaces are different.
I don't think that exposing serial numbers in /proc is a good
solution, both for the reasons already described and because I don't
think that iproute2 should need to muck around with /proc to function
correctly. Eric, any clever ideas here? Do we need fancier netlink
messages for this?
--Andy
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
From: Nicolas Dichtel <hidden> Date: 2014-08-25 16:41:41
Le 25/08/2014 18:13, Andy Lutomirski a écrit :
On Mon, Aug 25, 2014 at 8:43 AM, Nicolas Dichtel
[off-list ref] wrote:
quoted
Le 25/08/2014 16:04, Andy Lutomirski a écrit :
quoted
On Aug 25, 2014 6:30 AM, "Nicolas Dichtel" [off-list ref]
wrote:
quoted
quoted
CRIU wants to save the complete state of a namespace and then restore
it. For that to work, any information exposed to things in the
namespace *cannot* be globally unique or unique per boot, since CRIU
needs to arrange for that information to match whatever it was when
CRIU saved it.
How are ifindex of network devices managed? These ifindexes are unique
per boot,
thus can change depending on the order in which netdev are created.
These ifindexes are unique per boot and exposed to userspace ...
This does not appear to be true.
$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000
I've probably misunderstood what you're trying to say. ifindexes are unique
per
boot and per netns.
I think we both misunderstood each other. The ifindexes are unique
*per netns*, which means that, if you're unprivileged in a netns,
global information doesn't leak to you. I think this is good.
Ok, I agree. I think audit daemons are always running under privileged users.
quoted
quoted
Let me try again, with emphasis in the right place.
I think that *code running in a namespace* has no business even
knowing a unique identity of *that namespace* from the perspective of
the host.
In your example, if there's a veth device between netns A and netns B,
then code *in netns A* has no business knowing the identity of its
veth peer if its peer (B) is a sibling or ancestor. It also IMO has
no business knowing the identity of its own netns (A) other than as
"my netns".
I do not agree (see the example below).
quoted
If A and B are siblings, then their parent needs to know where that
veth device goes, but I think this is already the case to a sufficient
extent today.
I'm not aware of a hierarchy between netns. A daemon should be able to
got the full network configuration, even if it's started when this
configuration
is already applied, ie even if it doesn't know what happen before it starts.
I don't know exactly which namespaces have an explicit hierarchy, but
there is certainly a hierarchy of *user* namespaces, and network
namespaces live in user namespaces, so they at least have somewhat of
a hierarchy.
quoted
quoted
I feel like this discussion is falling into a common trap of new API
discussions. Can one of you who wants this API please articulate,
with a reasonably precise example, what it is that you want to do, why
you can't easily do it already, and how this API helps? I currently
understand how the API creates problems, but I don't understand how it
solves any problems, and I will NAK it (and I suspect that Eric will,
too, which is pretty much fatal) unless that changes.
What I'm trying to solve is to have full info in netlink messages sent by
the
kernel, thus beeing able to identify a peer netns (and this is close from
what
audit guys are trying to have). Theorically, messages sent by the kernel can
be
reused as is to have the same configuration. This is not the case with
x-netns
devices. Here is an example, with ip tunnels:
$ ip netns add 1
$ ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249 dev eth0
$ ip -d link ls ipip1
8: ipip1@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode
DEFAULT group default
link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
ipip remote 10.16.0.121 local 10.16.0.249 dev eth0 ttl inherit pmtudisc
$ ip link set ipip1 netns 1
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@tunl0: <POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
mode DEFAULT group default
link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
ipip remote 10.16.0.121 local 10.16.0.249 dev tunl0 ttl inherit pmtudisc
Now informations got with 'ip link' are wrong and incomplete:
- the link dev is now tunl0 instead of eth0, because we only got an ifindex
from the kernel without any netns informations.
- the encapsulation addresses are not part of this netns but the user
doesn't
known that (still because netns info is missing). These IPv4 addresses
may
exist into this netns.
- it's not possible to create the same netdevice with these infos.
Aha. That's a genuine problem.
Perhaps we need a concept of which netnses should be able to see each other.
Yes, I agree. This is not required for all netns, only a subset of netns should
be able to see each other.
I think I would be okay with a somewhat different outcome from your example:
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@[unknown device in another namespace]:
<POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
I think this outcome is mandatory if netns 1 lives in a subsidiary
user namespace.
Yes.
Certainly, if you do the 'ip link' in the original namespace, I agree
that this should work.
For most namespace types, this all works transparently, since
everything has an real identity all the way up the hierarchy. Network
namespaces are different.
I don't think that exposing serial numbers in /proc is a good
solution, both for the reasons already described and because I don't
think that iproute2 should need to muck around with /proc to function
A netlink API is probably enough. But it will help only for the network
problem, not for audit. I was hoping to find a common solution.
correctly. Eric, any clever ideas here? Do we need fancier netlink
messages for this?
--Andy
From: Andy Lutomirski <luto@amacapital.net> Date: 2014-08-25 16:50:36
On Mon, Aug 25, 2014 at 9:41 AM, Nicolas Dichtel
[off-list ref] wrote:
Le 25/08/2014 18:13, Andy Lutomirski a écrit :
quoted
On Mon, Aug 25, 2014 at 8:43 AM, Nicolas Dichtel
[off-list ref] wrote:
quoted
Le 25/08/2014 16:04, Andy Lutomirski a écrit :
quoted
On Aug 25, 2014 6:30 AM, "Nicolas Dichtel" [off-list ref]
wrote:
quoted
quoted
CRIU wants to save the complete state of a namespace and then restore
it. For that to work, any information exposed to things in the
namespace *cannot* be globally unique or unique per boot, since CRIU
needs to arrange for that information to match whatever it was when
CRIU saved it.
How are ifindex of network devices managed? These ifindexes are unique
per boot,
thus can change depending on the order in which netdev are created.
These ifindexes are unique per boot and exposed to userspace ...
This does not appear to be true.
$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000
I've probably misunderstood what you're trying to say. ifindexes are
unique
per
boot and per netns.
I think we both misunderstood each other. The ifindexes are unique
*per netns*, which means that, if you're unprivileged in a netns,
global information doesn't leak to you. I think this is good.
Ok, I agree. I think audit daemons are always running under privileged
users.
quoted
quoted
quoted
Let me try again, with emphasis in the right place.
I think that *code running in a namespace* has no business even
knowing a unique identity of *that namespace* from the perspective of
the host.
In your example, if there's a veth device between netns A and netns B,
then code *in netns A* has no business knowing the identity of its
veth peer if its peer (B) is a sibling or ancestor. It also IMO has
no business knowing the identity of its own netns (A) other than as
"my netns".
I do not agree (see the example below).
quoted
If A and B are siblings, then their parent needs to know where that
veth device goes, but I think this is already the case to a sufficient
extent today.
I'm not aware of a hierarchy between netns. A daemon should be able to
got the full network configuration, even if it's started when this
configuration
is already applied, ie even if it doesn't know what happen before it
starts.
I don't know exactly which namespaces have an explicit hierarchy, but
there is certainly a hierarchy of *user* namespaces, and network
namespaces live in user namespaces, so they at least have somewhat of
a hierarchy.
quoted
quoted
I feel like this discussion is falling into a common trap of new API
discussions. Can one of you who wants this API please articulate,
with a reasonably precise example, what it is that you want to do, why
you can't easily do it already, and how this API helps? I currently
understand how the API creates problems, but I don't understand how it
solves any problems, and I will NAK it (and I suspect that Eric will,
too, which is pretty much fatal) unless that changes.
What I'm trying to solve is to have full info in netlink messages sent by
the
kernel, thus beeing able to identify a peer netns (and this is close from
what
audit guys are trying to have). Theorically, messages sent by the kernel
can
be
reused as is to have the same configuration. This is not the case with
x-netns
devices. Here is an example, with ip tunnels:
$ ip netns add 1
$ ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249 dev
eth0
$ ip -d link ls ipip1
8: ipip1@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode
DEFAULT group default
link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
ipip remote 10.16.0.121 local 10.16.0.249 dev eth0 ttl inherit
pmtudisc
$ ip link set ipip1 netns 1
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@tunl0: <POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
mode DEFAULT group default
link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
ipip remote 10.16.0.121 local 10.16.0.249 dev tunl0 ttl inherit
pmtudisc
Now informations got with 'ip link' are wrong and incomplete:
- the link dev is now tunl0 instead of eth0, because we only got an
ifindex
from the kernel without any netns informations.
- the encapsulation addresses are not part of this netns but the user
doesn't
known that (still because netns info is missing). These IPv4
addresses
may
exist into this netns.
- it's not possible to create the same netdevice with these infos.
Aha. That's a genuine problem.
Perhaps we need a concept of which netnses should be able to see each
other.
Yes, I agree. This is not required for all netns, only a subset of netns
should
be able to see each other.
quoted
I think I would be okay with a somewhat different outcome from your
example:
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@[unknown device in another namespace]:
<POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
I think this outcome is mandatory if netns 1 lives in a subsidiary
user namespace.
Yes.
quoted
Certainly, if you do the 'ip link' in the original namespace, I agree
that this should work.
I think it should work if the peer userns is the same or a descendent.
I also wonder whether the peer's ifindex should be suppressed if peer
userns is not the same or a descendent.
Now you just have to get Eric to be happy with the id allocation. :)
This may be nontrivial.
quoted
For most namespace types, this all works transparently, since
everything has an real identity all the way up the hierarchy. Network
namespaces are different.
I don't think that exposing serial numbers in /proc is a good
solution, both for the reasons already described and because I don't
think that iproute2 should need to muck around with /proc to function
A netlink API is probably enough. But it will help only for the network
problem, not for audit. I was hoping to find a common solution.
I still don't understand why audit needs anything beyond the audit
part of this patch set. I have no problem with audit seeing that
migrated/restored namespaces are really brand-new namespaces, as long
as the code in those namespaces isn't exposed to it.
quoted
correctly. Eric, any clever ideas here? Do we need fancier netlink
messages for this?
--Andy
From: Richard Guy Briggs <hidden> Date: 2014-08-27 15:17:49
On 14/08/25, Andy Lutomirski wrote:
On Mon, Aug 25, 2014 at 9:41 AM, Nicolas Dichtel
[off-list ref] wrote:
quoted
Le 25/08/2014 18:13, Andy Lutomirski a écrit :
quoted
On Mon, Aug 25, 2014 at 8:43 AM, Nicolas Dichtel
[off-list ref] wrote:
quoted
Le 25/08/2014 16:04, Andy Lutomirski a écrit :
quoted
On Aug 25, 2014 6:30 AM, "Nicolas Dichtel" [off-list ref]
wrote:
quoted
quoted
CRIU wants to save the complete state of a namespace and then restore
it. For that to work, any information exposed to things in the
namespace *cannot* be globally unique or unique per boot, since CRIU
needs to arrange for that information to match whatever it was when
CRIU saved it.
How are ifindex of network devices managed? These ifindexes are unique
per boot,
thus can change depending on the order in which netdev are created.
These ifindexes are unique per boot and exposed to userspace ...
This does not appear to be true.
$ sudo unshare --net
# ip link add veth0 type veth peer name veth1
# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether 06:0d:59:c7:a6:a8 brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
link/ether b2:5c:8b:f2:12:28 brd ff:ff:ff:ff:ff:ff
# logout
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
state DOWN qlen 1000
I've probably misunderstood what you're trying to say. ifindexes are
unique
per
boot and per netns.
I think we both misunderstood each other. The ifindexes are unique
*per netns*, which means that, if you're unprivileged in a netns,
global information doesn't leak to you. I think this is good.
Ok, I agree. I think audit daemons are always running under privileged
users.
quoted
quoted
quoted
Let me try again, with emphasis in the right place.
I think that *code running in a namespace* has no business even
knowing a unique identity of *that namespace* from the perspective of
the host.
In your example, if there's a veth device between netns A and netns B,
then code *in netns A* has no business knowing the identity of its
veth peer if its peer (B) is a sibling or ancestor. It also IMO has
no business knowing the identity of its own netns (A) other than as
"my netns".
I do not agree (see the example below).
quoted
If A and B are siblings, then their parent needs to know where that
veth device goes, but I think this is already the case to a sufficient
extent today.
I'm not aware of a hierarchy between netns. A daemon should be able to
got the full network configuration, even if it's started when this
configuration
is already applied, ie even if it doesn't know what happen before it
starts.
I don't know exactly which namespaces have an explicit hierarchy, but
there is certainly a hierarchy of *user* namespaces, and network
namespaces live in user namespaces, so they at least have somewhat of
a hierarchy.
quoted
quoted
I feel like this discussion is falling into a common trap of new API
discussions. Can one of you who wants this API please articulate,
with a reasonably precise example, what it is that you want to do, why
you can't easily do it already, and how this API helps? I currently
understand how the API creates problems, but I don't understand how it
solves any problems, and I will NAK it (and I suspect that Eric will,
too, which is pretty much fatal) unless that changes.
What I'm trying to solve is to have full info in netlink messages sent by
the
kernel, thus beeing able to identify a peer netns (and this is close from
what
audit guys are trying to have). Theorically, messages sent by the kernel
can
be
reused as is to have the same configuration. This is not the case with
x-netns
devices. Here is an example, with ip tunnels:
$ ip netns add 1
$ ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249 dev
eth0
$ ip -d link ls ipip1
8: ipip1@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode
DEFAULT group default
link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
ipip remote 10.16.0.121 local 10.16.0.249 dev eth0 ttl inherit
pmtudisc
$ ip link set ipip1 netns 1
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@tunl0: <POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
mode DEFAULT group default
link/ipip 10.16.0.249 peer 10.16.0.121 promiscuity 0
ipip remote 10.16.0.121 local 10.16.0.249 dev tunl0 ttl inherit
pmtudisc
Now informations got with 'ip link' are wrong and incomplete:
- the link dev is now tunl0 instead of eth0, because we only got an
ifindex
from the kernel without any netns informations.
- the encapsulation addresses are not part of this netns but the user
doesn't
known that (still because netns info is missing). These IPv4
addresses
may
exist into this netns.
- it's not possible to create the same netdevice with these infos.
Aha. That's a genuine problem.
Perhaps we need a concept of which netnses should be able to see each
other.
Yes, I agree. This is not required for all netns, only a subset of netns
should
be able to see each other.
quoted
I think I would be okay with a somewhat different outcome from your
example:
$ ip netns exec 1 ip -d link ls ipip1
8: ipip1@[unknown device in another namespace]:
<POINTOPOINT,NOARP,M-DOWN> mtu 1480 qdisc noop state DOWN
I think this outcome is mandatory if netns 1 lives in a subsidiary
user namespace.
Yes.
quoted
Certainly, if you do the 'ip link' in the original namespace, I agree
that this should work.
I think it should work if the peer userns is the same or a descendent.
I also wonder whether the peer's ifindex should be suppressed if peer
userns is not the same or a descendent.
Now you just have to get Eric to be happy with the id allocation. :)
This may be nontrivial.
quoted
quoted
For most namespace types, this all works transparently, since
everything has an real identity all the way up the hierarchy. Network
namespaces are different.
I don't think that exposing serial numbers in /proc is a good
solution, both for the reasons already described and because I don't
think that iproute2 should need to muck around with /proc to function
A netlink API is probably enough. But it will help only for the network
problem, not for audit. I was hoping to find a common solution.
I still don't understand why audit needs anything beyond the audit
part of this patch set. I have no problem with audit seeing that
migrated/restored namespaces are really brand-new namespaces, as long
as the code in those namespaces isn't exposed to it.
Ok, I'm starting to get this... Perhaps /proc wasn't the best place to
expose this. Audit or an audit aggregator is the only one that needs to
know any of this information. This could be accomplished with
CAP_AUDIT_CONTROL and a new netlink audit message type to fetch
individual or all namespace IDs for a particular PID via auditctl, or by
having a CAP_AUDIT_WRITE-capable application pull the trigger to simply
dump that information to the log.
quoted
quoted
correctly. Eric, any clever ideas here? Do we need fancier netlink
messages for this?
--Andy
Andy Lutomirski
- RGB
--
Richard Guy Briggs [off-list ref]
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545