[2300] in linux-security and linux-alert archive
[linux-security] Re: Security problems in bind -- persisting?
daemon@ATHENA.MIT.EDU (Antonomasia)
Fri Jan 14 07:36:21 2000
Date: Fri, 14 Jan 2000 02:19:48 GMT
From: Antonomasia <ant@notatla.demon.co.uk>
Message-Id: <200001140219.CAA10532@notatla.demon.co.uk>
To: linux-security@redhat.com
Cc: kyle@U.Arizona.EDU
Resent-From: linux-security@redhat.com
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/ #
##############################################################
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe:
mail -s unsubscribe linux-security-request@redhat.com < /dev/null
