Date: Wed, 6 Jan 1999 00:21:35 +0300 From: Vadim Kolontsov <vadim@tversu.ru> To: freebsd-security@FreeBSD.ORG Subject: kernel/syslogd hack Message-ID: <19990106002135.A27566@tversu.ru>
next in thread | raw e-mail | index | archive | help
Hello,
UNIX syslog mechanism (both concept & implementation) is very
insecure. I'll not try to describe here all syslog's problems (it
worth making separate web page for it), but I'll propose a hack
for solving at least one.
I call it "fake local logs" problem. Syslog messages are too easy
to forge; for example, it can be sendmail error messages or some
other important information (imagine that you're really analyzing
your syslogd output with logsurfer :). Any user can do it.
syslogd uses UNIX domain socket (/var/run/log, for example) and
trusts every information from it (usually sent by syslog(3)). I
think it would be nice if syslogd would have an ability to determine
euid/uid/egid/egid/pid of process which sends log information
(directly to socket or via syslog(3)).
It's impossible to use lsof-like approach for it (walking through
kernel structures), because socket may be in not-connected state
or process which sent datagram may be already dead.
I've added additional socket option: SO_UNIXPRIVS. It's argument
is just int (true/false). It has sense only for UNIX domain datagram
socket. When kernel delivers datagrams for such socket, it adds
a special structure before the message:
struct unixprivs {
uid_t uid,euid;
gid_t gid,egid;
pid_t pid;
}
So syslogd can easily extract this information from incoming message.
Advantages: it doesn't require to recompile client applications or
shared libraries, it's completely transparent for clients, can be
used in other applications (I'm also thinking about some getpeeruid()
call for stream-based UNIX domain sockets -- I think it will just
walk through kernel structures (proc, p_fd, f_data, so_proto,
pr_domain..))
By the way, reading freebsd-security for a several years I can't
remember a question about getpeeruid()-like function, why? nobody
need it?
Disadvantages: after all, it's dirty hack. I understand that syslogd
should probably be rewritten (the best solution is to redesign the
whole syslog() mechanism). But I want to see pid/uid/gid for log
messages! Can you suggest anything better?
I'm interested in feedback. I'm going to release patches for FreeBSD
3.0's kernel and syslogd in a few days (it already works, but I
want to make it more clear). Here is example of output from my
syslogd (at home):
Jan 5 22:50:43 sb vadim/wheel/398 vadim: just test from logger
(uid) (gid)(pid)
Of course this patch doesn't solve problem with syslog/514 UDP. I
know it
See http://sb.123.org/syslogd_hack.html for updates - if any.
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?19990106002135.A27566>