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
| ||
|
Message-ID: <50C1FD9D.5020703@parallels.com> Date: Fri, 7 Dec 2012 18:30:53 +0400 From: Glauber Costa <glommer@...allels.com> To: Serge Hallyn <serge.hallyn@...onical.com> CC: Andrew Morton <akpm@...ux-foundation.org>, Rui Xiang <leo.ruixiang@...il.com>, <netdev@...r.kernel.org>, <containers@...ts.linux-foundation.org>, "Eric W. Biederman" <ebiederm@...ssion.com> Subject: Re: [PATCH RFC 0/5] Containerize syslog On 12/07/2012 06:23 PM, Serge Hallyn wrote: > Quoting Andrew Morton (akpm@...ux-foundation.org): >> On Mon, 19 Nov 2012 01:51:09 -0800 ebiederm@...ssion.com (Eric W. Biederman) wrote: >> >>> Are there any kernel print statements besides networking stack printks >>> that we want to move to show up in a new "kernel log" namespace? >> >> That's a good question, and afaict it remains unanswered. > > There are some other (not *terribly* compelling) cases. For instance > selinux hooks, if you say mount an fs without xattr support or with > unsupported options, will printk a warning. Things like stat.c and > capabilities and syslog print out warnings when userspace uses a > deprecated somethingorother - old stat syscall or sys_syslog without > CAP_SYSLOG. That should go to the container. Filesystems may give > warnings (bad mount options for tmpfs, bad uid owner for many of them, > etc) which belong in the container. Obviously some belong on the host - > if they show a corrupt superblock which may indicate an attempt by the > container to crash the kernel. > >> As so often happens, this patchset's changelogs forgot to describe the >> reason for the existence of this patchset. Via a bit of lwn reading > > Not as a separate justification admittedly, but the description was > meant to explain it: right now /dev/kmsg and sys_syslog are not safe > and useful in a container; syslog messages from host and containers > can be confusingly intermixed; and helpful printks are not seen in > the container. > >> and my awesome telepathic skills, I divine that something in networking >> is using syslog for kernel->userspace communications. >> >> wtf? > > Well, syslog is the kernel->userspace channel of last resort. > >> Wouldn't it be better to just stop doing that, and to implement a >> respectable and reliable kernel->userspace messaging scheme? > > Convenience functions on top of netlink? > >> And leave syslog alone - it's a crude low-level thing for random >> unexpected things which operators might want to know about. > > That sentence is a result of not calling a container admin an operator. > I can't argue it because I'm not sure whether to agree with that > classification. > I keep asking myself if it isn't the case of forwarding to a container all messages printed in process context. That will obviously exclude all messages resulting from kthreads - that will always be in the initial namespace anyway, interrupts, etc. There is no harm, for instance, in delivering the same message twice: one to the container, and the other to the host system. Isn't it natural that if the kernel printed something on behalf of a process, whoever is the admin of the machine that process lives on should see what it is about? -- 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