netdev - Re: [PATCH v3 00/11] Add namespace support for syslog

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: <87a9kkcc38.fsf@xmission.com>
Date:	Wed, 14 Aug 2013 12:21:47 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Rui Xiang <rui.xiang@...wei.com>,
	Gao feng <gaofeng@...fujitsu.com>, netdev@...r.kernel.org,
	containers@...ts.linux-foundation.org, serge.hallyn@...ntu.com,
	linux-kernel@...r.kernel.org, libo.chen@...wei.com,
	netfilter-devel@...r.kernel.org, guz.fnst@...fujitsu.com,
	akpm@...ux-foundation.org
Subject: Re: [PATCH v3 00/11] Add namespace support for syslog

"Serge E. Hallyn" <serge@...lyn.com> writes:

> Quoting Rui Xiang (rui.xiang@...wei.com):
>> On 2013/8/8 9:37, Gao feng wrote:
>> > On 08/07/2013 03:55 PM, Eric W. Biederman wrote:
>> >>
>> >> Since this still has not been addressed.  I am going to repeat Andrews
>> >> objection again.
>> >>
>> >> Isn't there a better way to get iptables information out than to use
>> >> syslog.  I did not have time to follow up on that but it did appear that
>> >> someone did have a better way to get the information out.
>> >>
>> >> Essentially the argument against this goes.  The kernel logging facility
>> >> is really not a particularly good tool to be using for anything other
>> >> than kernel debugging information, and there appear to be no substantial
>> >> uses for a separate syslog that should not be done in other ways.
>> > 
>> > containerizing syslog is not only for iptables, it also isolates the /dev/kmsg,
>> > /proc/kmsg, syslog(2)... user space tools in container may use this interface
>> > to read/generate syslog.
>> > 
>> > But I don't know how important/urgent this containerizing syslog work is,
>> > Rui Xiang, can you find an important/popular user space tool which uses this
>> > interfaces to generate kernel syslog?
>> > 
>> 
>> There are some other cases. Some warnings (bad mount options for tmpfs,
>> bad uid owner for many of them, etc) emerged in the container should
>> be exported to the container. Some belong on the host - if they show 
>> a corrupt superblock which may indicate an attempt by the container 
>> to crash the kernel. Like these, Kernel will print out warnings when 
>> userspace in container uses a deprecated something or other, and these
>> logs should be invisible and specific for current container.
>> 
>> I can't say this work is terribly compelling and important, but the 
>> impact may be obvious, IMO.
>
> Aug  9 21:49:13 sergeh1 kernel: [4644829.672768] init: Failed to spawn network-interface (veth8Ehlvj) post-stop process: unable to change root directory: No such file ricr:aeohgrticr  cfe rty444984 n:aetswnw-ta(ht -rrsultheoit: hlrro<4865i:i sntkta(ht ttpe btheoit: hlrrob r6ezt)nrgoadgte644915 c0pt(tyg ti wd a
> Aug  9 21:49:13 sergeh1 kernel: X3f d-6:uigitra ora
> Aug  9 22:19:54 sergeh1 kernel: 6[642.175 X3f d-6:mutdflsse ihodrddt oe==99 rfl=lccnanrdfutwt-etn"nm=/a/ah/x/lu-ui/m.AExdu"pi=91 om=mut sye"x3name="/devlo0" lg=r"ol pmc r=3an19pfel-nireu-tntgne/rc/cldudmHEqu d97o=otfy=x"ra=d/o/fg""8b:o vhc)nrgibdte646013 veeMzWe oso d<[4715]xr r1eMc egset
> Aug

That is certainly a mess.  Now I don't believe we allow processes in a
user namespace to write to the kernels log (certainly we shouldn't be)
so part of that is not a problem.

What is interleaving messages into syslog?

And to be clear my only perspective is that we need to make certain we
have this thought out.

Eric
--
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