Date: Thu, 7 Jan 1999 17:43:08 +0300 From: Vadim Kolontsov <vadim@tversu.ru> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: Don.Lewis@tsc.tdk.com, freebsd-security@FreeBSD.ORG Subject: Re: kernel/syslogd hack Message-ID: <19990107174308.A28043@tversu.ru> In-Reply-To: <199901071355.AAA12004@cheops.anu.edu.au>; from Darren Reed on Fri, Jan 08, 1999 at 12:55:55AM %2B1100 References: <19990107153615.A27741@tversu.ru> <199901071355.AAA12004@cheops.anu.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Darren,
> Just so I understand what you're doing, you're recording who sent the
> syslog message (and making the message longer) because you're concerned
> about users generating fake messages.
Yes, if kernel see that destination UNIX domain socket has special
option set, it adds pid/uid/gid/etc to all datagrams sent to this socket,
so syslogd can record this information to logs. So I can determine
later who is sending fake messages, who is flooding and so on..
This patch doesn't stop users to send fake message. But it allows
me to know *who* is sending it (it can be analyzed by human or by
log analyzing program).
To activate this behaviour in kernel, syslogd makes setsockopt("/var/run/log",
SOL_SOCKET, SO_MY_NEW_OPTION, &1). You only need to recompile kernel
and syslogd.
I've been suggested to modify syslog(3) to use sendmsg(2) with SCM_CREDS
instead of send()/sendto(). In this case kernel does the same work
(adding pid/uid/euid/gid/groups to the datagram). It requires to
recompile shared libraries and statically linked programs which
uses syslog(3), but I think it's anyway more "clear" way than patching kernel.
> Now as it stands, you don't want to stop them sending fake messages,
> you just want to know when they are being sent so you can distinguish
> real ones from fakes.
See above.. probably I didn't described the original idea well enough,
sorry. patching kernel and using SCM_CREDS with sendmsg(2) are just
two different ways to one target -- to allow syslog to record
information about process who sends logs.
> Btw, if you just wanted an enhanced configuration file, nsyslogd does
> filtering on IP#'s now.
I've tried nsyslogd, and I saw examples of it's configuration files.. it's
good, and I like it.
But now I'm thinking about FreeBSD's syslogd :)
Regards,
V.
--
Vadim Kolontsov
Tver Internet Center NOC
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990107174308.A28043>