-----BEGIN PGP SIGNED MESSAGE-----


  {I think that this doesn't belong on current. Tech-security or tech-net?}

>>>>> "Curt" == Curt Sampson <cjs@portal.ca> writes:
    Curt> On Sat, 16 Aug 1997, D'Arcy J.M. Cain wrote:

    >> I can't seem to use syslog in a chrooted environment.

    Curt> ISTR that this was a problem under SunOS which at least one
    Curt> program solved by using UDP to localhost instead of a
    Curt> unix-domain socket.

  FWTK does this. I don't like it.
  If you are concerned about security, and about getting reliable
auditing, then there are two options, both of which I've done:
	1. don't use syslog. Use files, or something. But, I prefer
	read-only chroot areas that are essentially empty, and live in
	their own slice.

	2. fix syslog.

  What is wrong with syslog:
	1. accepts spam from other nodes. Bad guy fills your logs. On
	security devices that stop all activity when they run out of
	audit space, this is a problem. If you do actions based on
	logs (e.g. swatch) then it is even worse. ("Boy who cried
	wolf")
	Solution: don't listen on inet sockets! This easy to do in the
	code actually, and I've done it.

	2. doesn't work with chroot(2). Oops, If you do #1, then you
	can't use 127.0.0.1. What to do? 
	   a. make /newroot/dev/log and teach syslogd to listen on it.
	   This works well, but doesn't scale to many chroot areas
	   well.
	   b. open /dev/log, chroot, change uid. This also works well,
	   but the executable must run as root for awhile, or you must
	   exec an executable that lives in the chroot area after you
	   give up root.

        3. datagram sockets are not reliable. If you run out of mbufs
	(obviously bad) you would expect to lose logging. If you
	openlog()'ed with LOG_CONS, then upon that write(2) failing,
	syslog tries to open /dev/console and write to it. If you
	happen to run X, and are out of mbuf's then your xterm -C may
	not get the console messages (this has been observed under
	SunOS and BSDi 2.0), and thus /dev/console winds up going to
	the real device.
	   On BSDi, there is a fixed sized buffer in their (I'm not
	real clear on what the details here) when X is running, and
	the write call can block and never unblock. On a Sparc
	machine, you get to scroll the screen in forth... So, under a
	heavy network load, you lose even *more* CPU. 

	  But the situation is actually worse: syslogd only gets a
	single 4k receive buffer. Once you have that many bytes of
	outstanding logs, write(2) begins to fail. syslogd can set as
	high as 64k but that doesn't always help, it just forstalls
	the inevitable.

  [All of these things were observed while I was technical manage at a
firewall vendor that was BSD based at the time. BTW: we also
discussed, but never properly implemented a mechanism to selectively
discard incoming packets when the mbuf usage was high. We could not
increase the mbuf allocation without complete SunOS source. We had
only 4.3 networking code source. What was implemented causes deadlocks
because TCP acks never arrive, so the mbuf's being held for un-acked
data never get freed.]

  Solutions:
  I hacked uipc_syscalls2.c (or so) to make SOCK_DGRAM Unix
domain sockets actually block in the write(2). This is *not* DGRAM
semantics, but in the limited use of Unix SOCK_DGRAM's that occured on
the firewall, this was easiest. 

  My preference is to switch from using Unix named sockets for logging
and introduce an unnamed socket type "AF_LOG" or something. It would
be flow controlled by default, but a setsockopt on the writer side
could make it discard things, or perhaps, the format of the data being
written should be known to the kernel, and LOG_DEBUG messages do get
discarded (or perhaps some combination of the two).

  Thoughts?

]  10s to Tokyo, 15m to the Cottage? What if I'm already there? | one quark   [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    | two quark   [
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

	
	
	
	



	
	
	
	
	
	

		

	
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBM/YWvsmxxiPyUBAxAQHT+wL7Bd68x2QkY0sXO+6V2h/N74eWc39pVL8Y
iJENUiWycL6wZLBGR4Y3Z61SjrUWNpjunJrZ34B6XdbNcFfgcnIqMlntzsl4g/fs
Cf8LunznU4o2UQwRBOVicfsLm31qAjVn
=p1qM
-----END PGP SIGNATURE-----