From owner-freebsd-security Tue Jan 5 13:23:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10234 for freebsd-security-outgoing; Tue, 5 Jan 1999 13:23:18 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from tversu.ru (mail.tversu.ru [62.76.80.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10127 for ; Tue, 5 Jan 1999 13:22:55 -0800 (PST) (envelope-from vadim@gala.tversu.ru) Received: from gala.tversu.ru (vadim@gala.tversu.ru [62.76.80.10]) by tversu.ru (8.8.8/8.8.8) with ESMTP id AAA10655 for ; Wed, 6 Jan 1999 00:19:33 +0300 (MSK) Received: (from vadim@localhost) by gala.tversu.ru (8.8.8/8.8.8) id AAA27583 for freebsd-security@freebsd.org; Wed, 6 Jan 1999 00:21:35 +0300 (MSK) Date: Wed, 6 Jan 1999 00:21:35 +0300 From: Vadim Kolontsov To: freebsd-security@FreeBSD.ORG Subject: kernel/syslogd hack Message-ID: <19990106002135.A27566@tversu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.15i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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