On Fri, Sep 15, 2000 at 11:55:23PM -0700, kmself@ix.netcom.com wrote: > > I'm aware of these limitations. You've got to work out acceptible > policies and risks while providing the tools to get the job done. The > problem I've had with direct root access is that users come on as root > from....some random IP (say, a dialup connection), and your accounting > goes all to shit. yes of course, that is why all my machines have this line in thier sshd_config: PermitRootLogin no then there is no more direct root login except on the console. as it should be. > With just a couple of users on a box (typical of servers I'm running), > it's pretty straightforward to check to see who's doing a bunch of "sudo > vi"s or "sudo bash"s (and you'll find my name in both sets of greps). [eb@socrates eb]$ tail -1 /var/log/sulog SU 09/15 03:09 + tty2 eb-root [eb@socrates eb]$ > The question is whether or not the servers are getting fscked up in the > process. quite true. > Basically, it comes down to a matter of trust -- do you trust your > people or don't you. The mix of sudo and full shell access means you > can restrict access (barring gross malfeasance), but also track, at > least to a resonable level of detail, what's going on. root's own > .bash_history file is another useful resource, and when it turns up > unexpectedly truncated, there are other issues at hand. Logging (root > commands, logs, etc.) to a third-party box with write-once, persistant > media is yet another option. yes but not really trivial to implement. sudo does nice logging, but its totally defeated when someone runs sudo bash. (you still have .bash_history but its hard to track things there to an individual) > It's easy to cover up tracks. It's a bit harder to cover up covering up > tracks. perhaps > We're only talking partial cross-purposes. I'm looking for a tool to > let me know at least when my admins are going full admin privileges, and > possibly to offer limited administrative powers to more restricted > users. I'm finding that the combination of prohibited root logins and > sudo gives me more control than direct root logins and su. Though su is > still used. Hmmm... Any way to prohibit su to root, I wonder. I think > so, have to look into it. add this line to your /etc/pam.d/su file: auth requisite pam_wheel.so group=wheel debug erb@socrates ~]$ id uid=1002(erb) gid=1002(erb) groups=1002(erb) erb@socrates ~]$ su su: Permission denied Sorry. erb@socrates ~]$ > Got any ideas for systems allowing for both a fine-grained level of > control *and* reasonable and flexibility for admins? capabilities? > Also, as this started off as a Debian thread somewhere/somehow, do you > have any suggestions for auditing a box through dpkg / apt, including > verification of packages (including checksum or signature tests where > possible), detecting binaries *not* associated with packages, and/or > possibly reinstalling a package over an existing instance? I believe > RPM has at least some of these capabilities, not sure that DEBs do. look at the packages, debsums and cruft, debsums can check md5sums on all files (if the package came with such a list, and not all do) cruft alegedly finds files unexplained by the packaging system, i have not quite figured out how to make cruft work though, it always starts spewing off every file and directory starting from / the problem with debsums is its trivial for a root to tamper with /var/lib/dpkg/info/foo.md5sums. a root can also just install a custom .deb, though this will be rather apparent the way dselect/apt operate. (apt will always replace a custom package with the real one if the versions are the same, dselect shows packages not listed in the Packages.gz file as `obsolete') ideally what is needed is some tripwire like functionality integrated into dpkg. tripwire is impossibly inconvenient if you install packages often or track unstable. really though if you have a hostile (or incompetant) root you can't get rid of your 120% screwed from the starting gate and there is not a damn thing you can do about it. (especially if your not the one who can get rid of them rather the oposite) -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpMrW1DwyZz0.pgp
Description: PGP signature