Re: using sudo (was Re: bash login for root)
On Fri, Sep 15, 2000 at 11:36:12PM -0800, Ethan Benson ([EMAIL PROTECTED]) wrote: On Fri, Sep 15, 2000 at 11:55:23PM -0700, kmself@ix.netcom.com wrote: 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 / ...and supposing debsums turns up some incorrectly checksummed packages? How do you go about correcting this? ...or do I remember reading about a reinstall w/ force option somewher 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. Oi, this would be cool. pgpOZyiI35zwo.pgp Description: PGP signature
Re: using sudo (was Re: bash login for root)
You should have a look a osh: $ apt-cache show osh Package: osh Priority: extra Section: shells Installed-Size: 67 Maintainer: Preston Smith [EMAIL PROTECTED] Version: 1.7-6 Depends: libc6 (= 2.1.2), libncurses5, base-files (= 2.1.6) Suggests: nvi Architecture: i386 Size: 45946 MD5sum: b53754d37bc5d58b8b8bc1c9afce772a Filename: dists/woody/main/binary-i386/shells/osh_1.7-6.deb Description: Operator's Shell The Operator Shell (Osh) is a setuid root, security enhanced, restricted shell. It allows the administrator to carefully limit the access of special commands and files to the users whose duties require their use, while at the same time automatically maintaining audit records. The configuration file for Osh contains an administrator defined access profile for each authorized user or group. The newest .deb in woody includes a white paper explaining the cocepts behind it. Looks close to what you're searching. Greetings, joachim
Re: using sudo (was Re: bash login for root)
On Fri, Sep 15, 2000 at 04:38:11PM -0800, Ethan Benson ([EMAIL PROTECTED]) 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 fromsome 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 vis or sudo bashs (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 pgpY4M0nphHFM.pgp Description: PGP signature
Re: using sudo (was Re: bash login for root)
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 fromsome 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 vis or sudo bashs (and you'll find my name in both sets of greps). [EMAIL PROTECTED] eb]$ tail -1 /var/log/sulog SU 09/15 03:09 + tty2 eb-root [EMAIL PROTECTED] 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: authrequisite pam_wheel.so group=wheel debug [EMAIL PROTECTED] ~]$ id uid=1002(erb) gid=1002(erb) groups=1002(erb) [EMAIL PROTECTED] ~]$ su su: Permission denied Sorry. [EMAIL PROTECTED] ~]$ 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/ pgpzegimRQuDA.pgp Description: PGP signature
Re: using sudo (was Re: bash login for root)
On Thu, Sep 14, 2000 at 03:11:42PM -0800, Ethan Benson ([EMAIL PROTECTED]) wrote: On Thu, Sep 14, 2000 at 12:31:27PM -0700, kmself@ix.netcom.com wrote: you could also accomplish this by creating mulitple uid=0 accounts with different passwords, at least that way if Tim gets his user password stolen its not an automatic root compromise. But you've got zero control of commands available, and no logging of what commands are being run as root. also if Nate was really evil/disgrunteled he may have installed a rootkit or backdoor before he was canned. in which case sudo or not your screwed anyway ;-) Modulo: if you suspect this up front, you can throttle his access in an instant, *without* disrupting the rest of the team. In no case do you have to worry about poor old Bob, who's just a dumb luser. Maybe you want to give him limited access to the print queue -- see the sudo docs for info on how to do this. Use of sudo also allows denying *all* remote root access. Hit the system as a normal user first, then go root. so does PermitRootLogin no and pam_wheel. Without the granularity of control by user and command, and logging. -- 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 pgpemH3IqxXAK.pgp Description: PGP signature
Re: using sudo (was Re: bash login for root)
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. even something as seemingly simple as `sudo make install' all one would have to do is create the following Makefile anywhere and run `sudo make install' to get a suid rootshell: install: install -o root -g evil -m 4750 /bin/bash /dev/.sh also if Nate was really evil/disgrunteled he may have installed a rootkit or backdoor before he was canned. in which case sudo or not your screwed anyway ;-) Modulo: if you suspect this up front, you can throttle his access in an instant, *without* disrupting the rest of the team. assuming he didn't already get the chance to install a backdoor. in which case its reinstall time. 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) -- Ethan Benson http://www.alaska.net/~erbenson/ pgp1ZzyvDTXMQ.pgp Description: PGP signature
using sudo (was Re: bash login for root)
On Wed, Sep 13, 2000 at 10:23:14PM -0800, Ethan Benson ([EMAIL PROTECTED]) wrote: On Wed, Sep 13, 2000 at 08:56:32PM -0700, Bob Nielsen wrote: I use sudo, logged in as a regular user. It's generally considered a security risk to be logged in as root, and a bit less of a risk to use sudo or fakeroot. well it depends on how you setup sudo, IMO letting your non-privileged account run anything as root via sudo is a bad idea. it essenially turns your non-privileged account password into the root password. sudo bash yeck. The advantage in a multiuser environment is that you providing (and controlling) root access at the user level rather than at the system level. Eg, Tim, Bob, Alice, and Nate have access to a system. Tim, Alice, and Nate are admins. Nate is canned for violating company SOP. If Tim, Alice, and Nate shared the root password, you need to: - Change the root password. - Tell Tim and Alice If root access was provided via sudo: - Remove Nate from the /etc/sudoers file. In no case do you have to worry about poor old Bob, who's just a dumb luser. Maybe you want to give him limited access to the print queue -- see the sudo docs for info on how to do this. Use of sudo also allows denying *all* remote root access. Hit the system as a normal user first, then go root. Ideally, the root account password is simply not well known, and console admin is done only when absolutely required, with password being created at this time or unsealed as needed. -- 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 pgpaOQu5RNml6.pgp Description: PGP signature
Re: using sudo (was Re: bash login for root)
On Thu, Sep 14, 2000 at 12:31:27PM -0700, kmself@ix.netcom.com wrote: The advantage in a multiuser environment is that you providing (and controlling) root access at the user level rather than at the system level. Eg, Tim, Bob, Alice, and Nate have access to a system. Tim, Alice, and Nate are admins. Nate is canned for violating company SOP. If Tim, Alice, and Nate shared the root password, you need to: - Change the root password. - Tell Tim and Alice If root access was provided via sudo: - Remove Nate from the /etc/sudoers file. you could also accomplish this by creating mulitple uid=0 accounts with different passwords, at least that way if Tim gets his user password stolen its not an automatic root compromise. also if Nate was really evil/disgrunteled he may have installed a rootkit or backdoor before he was canned. in which case sudo or not your screwed anyway ;-) In no case do you have to worry about poor old Bob, who's just a dumb luser. Maybe you want to give him limited access to the print queue -- see the sudo docs for info on how to do this. Use of sudo also allows denying *all* remote root access. Hit the system as a normal user first, then go root. so does PermitRootLogin no and pam_wheel. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpRoT10i5jG0.pgp Description: PGP signature
