netdev - Re: [PATCH RFC 0/5] Containerize 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] [day] [month] [year] [list]

Date:	Wed, 12 Dec 2012 12:08:50 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Glauber Costa <glommer@...allels.com>
Cc:	Serge Hallyn <serge.hallyn@...onical.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rui Xiang <leo.ruixiang@...il.com>, <netdev@...r.kernel.org>,
	<containers@...ts.linux-foundation.org>
Subject: Re: [PATCH RFC 0/5] Containerize syslog

This conversation is really debating the wrong question.

The fundamental question is can we modify the kernel such that
containers don't care about anything that goes into the kernel log.

The fundamental question leads to the question what functionality
that is logged to the kernel log must we see in containers.

Serge has a collected a lot of cases and it seems reasonable to assume
that we will find those cases that must show up in a container or
require huge userspace reworking.

These messages that must show up in a container (or break userspace) are
messages that already exist today.  These messages quite likely are
specific to the container itself and I don't think we will need to
double log them.

But the first step of the process is to find the kernel messages that if
we don't log to user space via the kernel log will break user space.

Once we have found those messages and the cases in which there are no
work-arounds we can refine the design with nice to haves.

But this conversation really needs to be about which messages must we
deliver to userspace via the kernel log.

There are a lot of nice to haves messages out there.  Mount failures,
selinux failures etc.  Some of those have a pretty compelling case to be
double logged.

I think for the compelling cases we won't want to doulbe log them, and
those compelling cases need to drive the design.

The most compelling case I know of are firewall log messages that are
logge by explicit user request when selected packets hit the local
firewall.  Those messages I definitely don't want to double log and
those messages are most definitely not interesting to the operator of
the machine.  Those messages are only interesting to the admin who
configured his firewall to log them.

We should look to see if there are alternatives to user configured
firewall log messages that a system administratrator can use.  If not we
have our first compelling case for this functionality.

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