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:	Mon, 29 Jul 2013 11:58:23 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Rui Xiang <rui.xiang@...wei.com>
Cc:	<containers@...ts.linux-foundation.org>,
	<linux-kernel@...r.kernel.org>, <serge.hallyn@...ntu.com>,
	<akpm@...ux-foundation.org>, <gaofeng@...fujitsu.com>,
	<libo.chen@...wei.com>
Subject: Re: [PATCH 0/9] Add namespace support for syslog v2

Rui Xiang <rui.xiang@...wei.com> writes:

> This patchset introduces a system log namespace.

The largest outstanding question is not answered.  Can't we just fix
iptables to log somehwere better than dmesg, and would that not entirely
remove the need for this work?

That question needs to be answered before we proceed down this path.

Eric

> It is the 2nd version. The link of the 1st version is 
> http://lwn.net/Articles/525728/. In that version, syslog_
> namespace was added into nsproxy and created through a new
> clone flag CLONE_SYSLOG when cloning a process. 
>
> There were some discussion in last November about the 1st 
> version. This version used these important advice, and 
> referred to Serge's patch(http://lwn.net/Articles/525629/).
>
> Unlike the 1st version, in this patchset, syslog namespace 
> is tied to a user namespace. Add we must create a new user 
> ns before create a new syslog ns, because that will make 
> users have full capabilities in this new userns after 
> cloning a new user ns. The syslog namespace can be created 
> through a new command(11) to __NR_syslog syscall. That owe 
> to a new syslog flag SYSLOG_ACTION_NEW_NS.
>
> In syslog_namespace, some necessary identifiers for handling 
> syslog buf are containerized. When one container creates a
> new syslog ns, individual buf will be allocated to store log
> ownned this container. 
>
> A new interface ns_printk is added to print the logs which 
> we want to see in the container. Through ns_printk, we can 
> get more logs related to a specific net ns, for instance, 
> iptables. Here we use it to report iptable logs per 
> contianer.
>
> Then default printk targeted at the init_syslog_ns will 
> continue to print out most kernel log to host.
>
> One task in a new syslog ns could affect only current 
> container through "dmesg", "dmesg -c" and /dev/kmsg 
> actions. The read/write interface such as /dev/kmsg, 
> /pro/kmsg and syslog syscall continue to be useful for 
> container users.
>
> This patchset is based on linus' linux tree.
>
> Rui Xiang (9):
>   syslog_ns: add syslog_namespace and put/get_syslog_ns
>   syslog_ns: add syslog_ns into user_namespace
>   syslog_ns: add init syslog_ns for global syslog
>   syslog_ns: make syslog handling per namespace
>   syslog_ns: make permisiion check per user namespace
>   syslog_ns: use init syslog_ns for console action
>   syslog_ns: implement function for creating syslog ns
>   syslog_ns: implement ns_printk for specific syslog_ns
>   netfilter: use ns_printk in iptable context
>
>  fs/proc/kmsg.c                 |  17 +-
>  include/linux/printk.h         |   5 +-
>  include/linux/syslog.h         |  79 ++++-
>  include/linux/user_namespace.h |   2 +
>  include/net/netfilter/xt_log.h |   6 +-
>  kernel/printk.c                | 642 ++++++++++++++++++++++++-----------------
>  kernel/sysctl.c                |   3 +-
>  kernel/user.c                  |   3 +
>  kernel/user_namespace.c        |   4 +
>  net/netfilter/xt_LOG.c         |   4 +-
>  10 files changed, 493 insertions(+), 272 deletions(-)
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ