Xref: utzoo comp.unix.wizards:23245 alt.security:1228
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!swrinde!ucsd!nosc!logicon.com!Makey
From: Makey@Logicon.COM (Jeff Makey)
Newsgroups: comp.unix.wizards,alt.security
Subject: Re: not using syslogd in the first place
Message-ID: <735@logicon.com>
Date: 2 Aug 90 00:27:58 GMT
References: <1990Jul31.141746.27004@athena.mit.edu> <18210:Aug103:35:0890@kramden.acf.nyu.edu> <1990Aug1.052525.22007@athena.mit.edu> <4559:Aug121:33:5590@kramden.acf.nyu.edu>
Distribution: usa
Organization: Logicon, Inc., San Diego, California
Lines: 25

In article <4559:Aug121:33:5590@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>I can flood /dev/log with messages, clogging syslog. That's secure?
>
>If I were a cracker who had just achieved root, I would have to replace
>or restart *one* program to avoid *all* future detection. That's right,
>all security logging goes through *one* hook. There is *no* reliability.
>There is *no* backup. That's secure?

Except when "security through obscurity" actually succeeds, the idea
that a UNIX system can in any way be protected from someone with root
access is completely absurd.  Naturally, any standard method of
exception logging (e.g., stderr, syslog) will be insufficiently
obscure to provide the desired security.

From a security point of view, there are no redeeming features
whatsoever in logging to a file (via stderr in Dan's implementation)
in the face of root access.  On the other hand, if logging is done to
a remote machine then there is a possibility of at least *detecting* a
break-in (assuming, of course, that the loghost is not compromised).

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey