Date: Mon, 24 Feb 1997 17:20:23 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: Adrian Chadd <adrian@cougar.aceonline.com.au> Cc: hackers@freebsd.org, auditors@freebsd.org Subject: Re: disallow setuid root shells? Message-ID: <Pine.BSF.3.95.970224171452.14441E-100000@alive.znep.com> In-Reply-To: <Pine.LNX.3.93.970225064152.11428A-100000@cougar.aceonline.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 25 Feb 1997, Adrian Chadd wrote: > On Mon, 24 Feb 1997, Nate Johnson wrote: > > > %well the security audit should pick up any new suid files each night, > > > > Except the case where the hacker truly knows what they're doing, in which > > case, the security audit will be worthless. root can modify any files he > > wants, including the database used to compare suid files against. =( > > > > An extension of what I said before - what about logging ALL setuid > programs? And not in the program source (of course), but in the kernel? > Tis just an idea. > > Btw - yes I know adduser isn't suid, sorry, I just woke up .. now I've had > my coffee things are clearer. :) process accounting sortof does that: lastcomm: (after enabling process accounting, of course) passwd -S marcs ttyp1 0.09 secs Mon Feb 24 17:14 The S says used superuser privs. That is only a partial implementation, though, since process accounting logs aren't the nicest to log remotely, they contain a whole lot of other programs, and the S flag is only set if something the process calls suser(); ie. something it calls ends up resulting in suser being called by something. A lot can be done without doing that. Process accounting may be something to start for that type of logging.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970224171452.14441E-100000>