From owner-freebsd-security Tue Jul 6 2:55:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 17BDE153CC for ; Tue, 6 Jul 1999 02:55:36 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id FAA05009; Tue, 6 Jul 1999 05:55:34 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Tue, 6 Jul 1999 05:55:34 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Dean Cc: freebsd-security@FreeBSD.ORG Subject: Re: Tracking Root Users In-Reply-To: <4.1.19990706014149.00963570@mail.thegrid.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org With auditing support in kernel, this should not be a problem. However, it would be necessary to protect a userland support daemon from interference by other processes. There are various ways to do this that might be tied into the securelevel system. One thing I had in mind was processes flagged appropriately would not be signalable/debuggable/etc after the securelevel was raised above the processes starting securelevel. This would mean that auditd started before the bumping of the securelevel would be fairly immune to interference (leaving aside lack of disk space) following boot. This would not protect it against denial of service due to lack of disk space, etc, etc, but would at least prevent it from being killed or attacked using debugging. Presumably the config file would also need to be protected, etc. On Tue, 6 Jul 1999, Dean wrote: > At 03:04 PM 7/1/99 -0400, Master Of Spirits wrote: > >I have found that the simplest way (which I use myself) it a few > >modifictions to the shells themself, and to syslog.conf. For the purposes > >of tracking commands used by uid 0, the shells script waits for su to > >send a confirmed su signal and then logs to a log file and continues to > >log all commands sent through the shell untill su sends a termination > >signal. This bypasses syslog entirely save for the notification of a > >failed or successful SU attempts. Minor adustments could also pipe this > >feedback to a printer or external device, thus removing the possibility of > >hackers editing the logs themselves. > > > >-= UNACOM System Admin =- > > That is a great idea, but an attacker could simply change shells directly > after su-ing. I suppose all you need do is build this extra logging into > each shell you have on your machines. Course, the attacker could import > his own shell to get around that.... Maybe some sort of program that > listens to the tty. > My two cents, > Dean > ------------------------------------------------------------------------------- > A train stops at a train station, a bus stops at a bus > staion. On my desk, I have a workstation.... > ------------------------------------------------------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message