[linux-security] Re: Security problems in bind -- persisting?

[Antonomasia <ant notatla demon co uk>]

Kyle Ferrio:

> Unfortunately, his last act was to rm -rf /var/log so I don't know
> exactly how he got root.  Definitely a remote exploit, though.
> Does anyone have advice on mirorring syslog to "secret" locations,
> preferably encrypted?  Losing logs makes it hard to do a risk assessment.
> For all I know, I'm still vulnerable after updating bind.

As for safe logging I suggest serial lines onto a standalone box.
This is recommended in such well-regarded places as Chapman & Zwicky's
book "Building Internet Firewalls", ORA, page 106.  When I came to do
this I could find no software so I wrote some (at work, unpublished).

Essentially what you want is a bit of serial traffic code lifted from the
HOWTOs in both a source and a sink:

source:
   syslog sends to a named pipe
   daemon copies named pipe down the serial link

sink:
   a config file to read
      This will list the serial ports to read, and their baudrates etc.
      Also a log rotation policy.  I coded a few, of which probably the
      best one was to rotate files at a (configurable) size and keep a
      (configurable) number of them.   With the constraint that no file
      is removed under an age of 3 months.
   a select() to see when there is new data on each serial port in use
      (I had it happily using 2, didn't try more.)
   a directory per serial port to store logfiles in, absolutely
      raw as they arrive, but separated out into different files 
      (at log entry joins) to keep file size small

There was also a metalog file recording log rotations on the data
streams (filenames, sizes and times).  By keeping this out of band it
could not be spoofed by anything coming down the serial line.
The metalog also contains a daily traffic summary that you can watch
to see easily if something is being flooded or a serial port has died.

It should only take a few days; even if you are new to serial port
programming as I am.


You can run bind non-root in a chroot jail.  Escaping from that is
supposed to be impossible.  I have confirmed that my (work) bind runs
as the "named" user in all 4 IDs shown by "cat /proc/XXX/status".

Does anyone know adverse effects (beside added net traffic) of simply
not running bind ?

To make your kernel refuse double chroot()s even for root is this the test
people would do in fs/open.c ?
        if (memcmp(current->fs->root,
                   task[1]->fs->root,
                   sizeof(struct inode))) {

And what would be the best response to a failure ?  I'm logging and
sending a SIGKILL, but I suspect that's not ideal.


--
##############################################################
# Antonomasia   ant notatla demon co uk                      #
# See http://www.notatla.demon.co.uk/                        #
##############################################################