Date: Tue, 5 Jan 1999 16:39:53 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Vadim Kolontsov <vadim@tversu.ru>, freebsd-security@FreeBSD.ORG Subject: Re: kernel/syslogd hack Message-ID: <199901060039.QAA13314@salsa.gv.tsc.tdk.com> In-Reply-To: Vadim Kolontsov <vadim@tversu.ru> "kernel/syslogd hack" (Jan 6, 12:21am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 6, 12:21am, Vadim Kolontsov wrote: } Subject: kernel/syslogd hack } 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 possible to do this in current by using SCM_CREDS with sendmsg(). } Advantages: it doesn't require to recompile client applications or } shared libraries, it's completely transparent for clients, can be If you wanted to use SCM_CREDS, you'd need to tweak syslog() and rebuild the shared library. I don't think this is too much of a disadvantage. } 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..)) What if there are multiple processes at the other end? If a process calls connect() and then fork(), the socket created by accept() in the server will have multiple peer processes. } Of course this patch doesn't solve problem with syslog/514 UDP. I } know it Someone has written a secure syslog protocol that uses encryption, etc. --- Truck 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?199901060039.QAA13314>