Date: Mon, 28 Jul 1997 10:26:47 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: adam@homeport.org (Adam Shostack) Cc: adam@homeport.org, dholland@eecs.harvard.edu, robert@cyrus.watson.org, security@FreeBSD.ORG Subject: Re: secure logging (was: Re: security hole in FreeBSD) Message-ID: <199707281726.KAA18251@GndRsh.aac.dev.com> In-Reply-To: <199707281604.MAA04611@homeport.org> from Adam Shostack at "Jul 28, 97 12:04:52 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Rodney W. Grimes wrote: > | > Reliability: The system must make substantial efforts to not > | > lose information. > | > > | > Network Requirements > | > TCP based > | > Application sequencing with explicit ack before sender deletes > | > | How are you going to handle the log server going away and coming back?? > > The client will have to queue messages. Its possible that TCP > message queueing will handle this, its also possible that the > application will need some retransmit smarts, which would be > unfortunate, since it adds a good deal of complexity. TCP message queueing won't handle the fact that the server has rebooted and the connection is going to get a ``reset by peer'' next time you try to send data on it. Your going to need some very robust code ala what NFSV3 over TCP does in order to handle the server coming and going. > Should there be a capability for multiple log servers (like > mail?) Probably a really good thing! > | > Application Reliability > | > NO data discarding > | > Solid message handling locally-messages kept until discard > | > Repeated message management (?) > | > > | > Portability > | > External Alerting > | > External Intrusion Detection linking > | > | Security: The data over the network must be unreadable > | unless a secret is known. Syslog data can contain > | confidential information. > > Is confidentiality or authenticity important? For my Both confidentiality and authenticity are important. Realize syslog may be logging login failures, some systems pass the attempted username in login failure cases, and often this is a passwd due to out of sequence data entry (user entered passwd at username prompt). Go grep /var/log/messages on a few 100 timeshareing systems and you can often come up with a password or two, then you just have to match it to a user... > purposes, its authentication. Should we simply allow the use of IPsec > or SSH port forwarding for confidentiality and authentication? It > cuts complexity substantially. That would be one solution, but not all hosts implement IPsec. SSH would work, but SSH can't handle the fact that the server got rebooted and you have to establish a new connection. > | How about just converting syslog/syslogd to handle a kerberized > | t/tcp connection?? > > Syslog still discards data when its local daemon cache gets too full. No matter what you do your not going to totally fix the discard data problem. Even a malloc'ed data structure will sooner or later fill all memory and all swap space. A disk based queue could fill all disk space. This ``discard data'' problem is a real bear! > It discards data when forwarding messages from host a via host B to > host C. (Yes, real case.) It loses priority and type when putting > messages into files > > Not that kerberizing a TCP based syslog would be bad, I just don't > think its sufficient. But it is a steep in the right direction. Could be implemented in a day or two of work. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707281726.KAA18251>