On Fri, Sep 15, 2000 at 04:38:11PM -0800, Ethan Benson (erbenson@alaska.net) wrote: > On Fri, Sep 15, 2000 at 03:47:48PM -0700, kmself@ix.netcom.com wrote: > > > > But you've got zero control of commands available, and no logging of > > what commands are being run as root. > > true, but this goes back to my original comment that allowing a user > account to run anything as sudo does nothing but turn it into another > root account, if you want the granularity, loging and control you > mention you have to take GREAT care in what you let a `sudoer' do, > otherwise he can just run `sudo bash' and there goes your loging, and > granularity right there. or something more insidious like this: > > sudo emacs > M-x shell > > the same works with vi and loads of other editors. 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. 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). The question is whether or not the servers are getting fscked up in the process. 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. It's easy to cover up tracks. It's a bit harder to cover up covering up tracks. > > Without the granularity of control by user and command, and logging. > > yes but see above. (i think we are talking about different things, i > am talking about giving another admin full root privileges, where your > talking about giving a admin or assistent just very partial restricted > access) 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. Got any ideas for systems allowing for both a fine-grained level of control *and* reasonable and flexibility for admins? 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. -- Karsten M. Self <kmself@ix.netcom.com> http://www.netcom.com/~kmself Evangelist, Opensales, Inc. http://www.opensales.org What part of "Gestalt" don't you understand? Debian GNU/Linux rocks! http://gestalt-system.sourceforge.net/ K5: http://www.kuro5hin.org GPG fingerprint: F932 8B25 5FDD 2528 D595 DC61 3847 889F 55F2 B9B0
Attachment:
pgprF6TiJtxnz.pgp
Description: PGP signature