Date: Thu, 1 Jul 1999 15:16:11 +0200 (CEST) From: Ben Gras <ben@nl.euro.net> To: freebsd-security@freebsd.org Subject: Re: how to keep track of root users? Message-ID: <199907011316.PAA22709@support.euronet.nl> In-Reply-To: <Pine.LNX.4.05.9907012223390.5912-100000@zipper.zip.com.au> from Nicholas Brawn at "Jul 1, 99 10:29:19 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Folks, > It appears that the process accounting in FreeBSD is a remnant of a bygone > era, where all cpu time was costly and had to be accounted for. From a > security perspective, process accounting would need to: > - log uid, gid, and euid of the user calling the process. > - log the process name, executable name, and path to the executable. > - log arguments to the process being executed. > - log date and amount of time the process took to complete. > - log the tty the user who called the process executed it from. Hmm, this isn't quite that simple; then we're dealing with . forks: Log uid/gid/euid/pid of parent, and pid of child. . execs: Log arguments and "process stack" (parent and it's ancestors; the pid and process p_comm for each process). Also log executable used (filesystem + inode number + lookup path + the root used to do the lookup, along with md5 of the executable in a perfect world). . exits: Log pid, exit code and/or signal. (I think that's all. setuid/seteuid/setgid/setegid/chroot and several others could be useful too.. hmm. this smells like a flexible rule-based config.) After all, a process might exec() multiple times, or fork() without exec()ing, or exec() multiple times before execing, not showing up in the accounting logs (that command that is; it'll show up as the last exec() I suppose) -- so accounting isn't flexible enough. Also p_comm isn't very meaningful at all (as far as I can see) if you're dealing with someone purposefully trying to hide what he's doing. I've already written a kernel extension that provides this, more elaborate, kind of logging, the idea is to syslog it to a remote host (or line printer :)) to create a trail of actions that have ever happened on systems, so should the box ever be hacked into, one can go to the secure host and reconstruct how it was done (well.. often) and what was done afterwards (root commands to install back doors, cover tracks etc). Especially the process "stack" mentioned above is useful in putting things in perspective. The log works quite well, I'm just concerned it'll eat a lot of CPU on the system it runs on, and will eat lots of network bandwidth too.. the idea, however, is nice :). I realized at the time that an accounting-style file is better suited for this information than syslog is; however, accounting doesn't work that way.. (It logs the information on exit()ing, which isn't the right time to gather all the information we want to log, it's too little too late, it's just not what it's meant to do.) Ehm is this making sense yet? =Ben 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?199907011316.PAA22709>