[Devel] Re: [lxc-devel] Containerized syslog

[Serge E. Hallyn]

Quoting Matt Helsley (matthltc at us.ibm.com):
> On Wed, May 12, 2010 at 11:15:05PM +0200, Daniel Lezcano wrote:
> > Jean-Philippe Menil wrote:
> > > Hi,
> > >
> > > I'm playing with containers under debian (squeeze, 2.6.33.3) with the 
> > > lxc tools.
> > > I'm really happy about all the features (attach veth on bridge, filter 
> > > with iptables inside the containers, etc ...), and i was thinking to 
> > > replace some of our vservers (and maybe some of our kvm) with this 
> > > solution.
> > >
> > > But actually, i experiment a problem with the iptables logs:
> > > i've iptables on the host to filter some container, basically a squid 
> > > proxy. I've another container who act as router, and he has his own 
> > > iptables inside.
> > > All the log are deported to a dedicated syslog server.
> > > It appear that, the iptables log of the host are also deported by the 
> > > syslog container (proxy).
> > >
> > > Some of our guest (container, vserver, etc ) are administer by other 
> > > sys-admin, that should not have access to theses informations.
> > >
> > > This point is blocking me today, before going into production with 
> > > containers.
> > >
> > > I've seen some patch made by Jean-Marc Pigeon about this problem,
> > > but they have not been commited.
> > 
> > I thing a consensus was not reach. The big deal with syslog is netfilter 
> > logs in an interrupt context where it is difficult to find the right log 
> > buffer ring as we are not in the process context making possible to 
> > identify the namespace.
> > 
> > IMHO, there are two parts to implement, (1) multiple instances of 
> > /dev/log with a new ring buffer each time attached to the file and 
> 
> Just for reference, here are some archived mailing list threads on the
> subject of containerized syslog:
> 
> 	http://www.mail-archive.com/devel@openvz.org/msg20104.html
> 	http://thread.gmane.org/gmane.linux.kernel.containers/16526
> 
> > (2) 
> > add an iptables rules to specify the file to log. This approach allows 
> > to get rid of namespace (in all the cases the clone flags are exhausted 
> > now), and provides a generic mechanism for other use cases (eg. separate 
> > logs for iptables) different from a container specific problem.
> 
> (3) Security implications.
> 
> 	Depending on how the syslog is split off, whether the host
> 	expects to be "Cc'd", etc. there could be some security
> 	implications. More importantly, the syslog control syscalls need
> 	to be modified to at least prevent containers from changing syslog
> 	policy of the host. Serge could probably explain this much better
> 	than I can (cc'd). Here's a thread on the subject:
> 
> 	http://lwn.net/Articles/378472/

Yes, i think that's the first step.  Then, as Oren and Matt were
discussing on irc, we can talk about a userspace daemon on the host
forwarding either syslog or audit msgs to containers as appropriate.
This leaves that policy chunk in userspace, but we'd still have to
decide on a way to mark messages (which is why audit would be
easier).  First question then is how do we identify a container?
With pidns we can point to a definitive global pid for the container
init task.  For netns, no such thing.

-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers