Date: Tue, 6 Jul 1999 05:55:34 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Dean <dean@thegrid.net> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Tracking Root Users Message-ID: <Pine.BSF.3.96.990706055309.296C-100000@fledge.watson.org> In-Reply-To: <4.1.19990706014149.00963570@mail.thegrid.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990706055309.296C-100000>