[syslog-ng]replacing Linux klogd by a chrooted syslog-ng running as a non root user

[Guillaume LACHENAL]

Balazs Scheidler wrote :
> On Thu, Nov 07, 2002 at 02:25:44PM +0100, Guillaume LACHENAL wrote:
> > from  http://www.campin.net/syslog-ng/faq.html
> > 
> > As /proc/kmsg and /dev/log are outside the jail, is there a way to do 
the
> > same thing with a chrooted syslog-ng ?
> 
> configuration initialization is performed prior to chroot-ing, so 
syslog-ng
> first opens the necessary devices, and then chroots itself.

OK. So if I understand when using syslog-ng '-C' options there is no need
that $JAIL/etc contains syslog-ng.conf. It can stay in /etc
 
> you cannot restart the daemon though, unless you do the following:

OK I've seen it. You make me not to create a new thread on the list ;-)

Is it for the same reasons that I have (almost) every time to send SIGTERM 
*twice*
for syslog-ng to terminate ?
 
> - mount /proc under the chroot jail as well (can be mounted multiple 
times)
> - create a symlink in /dev/log to /chroot/dev/log
> 
> then instead of using syslog-ng's own chroot feature, use the chroot

Are you sure a chrooted process can follow symlinks outside the jail ?

> command, so the config initialization is performed _inside_ the jail. 
These
> have drawbacks as well:
> 
> - you need libc and other libs in the jail (while when starting from
>   outside, these are mapped from the system at startup)

libc is also needed when using the '-C' switch !

ldd syslog-ng
        libnsl.so.1 => /lib/libnsl.so.1 (0x00126000)
        libc.so.6 => /lib/libc.so.6 (0x0013d000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00110000)

and I've 'discover' during my jail creation that libresolv and libnss_*
are also needed 
(remember the thread "chroot and hostname resolution problem [was : Re: 
[syslog-ng]centralized loghost]")

I don't think we can say it's a drawback

> - /proc might provide too much information inside the jail so you might 
as
>   well run syslog-ng outside the jail ;)

Exactly opposite to the secure way we try to follow ;-)
 
> The latter problem can be solved by restricting /proc access with a 
patch
> like openwall, and I might provide a patch for the first, to chroot 
first,
> and then initialize.

I'll check it latter, when my platform will be 100% OK and have more spare
time ;-)

Thanks

Regards

Guillaume