Re: shared root account
On Tue, Jul 17, 2001 at 04:17:23AM -0800, Ethan Benson wrote: > On Tue, Jul 17, 2001 at 12:29:45PM +0100, Nick Phillips wrote: > > On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote: > > > > > nice to know pam_pwdfile gained md5 support, iirc it only did the > > > anchient crappy crypt before.. > > > > > > now there just needs to be a passwd command to work with this... > > > > htpasswd > > doesn't provide proper restrictions and authentication. (for other > uses then sudo passwords). > > whats really needed is a passwd command that behaves exactly the same > as passwd, only with alternate passwd files. Hmm, shouldn't some PAM-aware passwd implementation be able to do this? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
Re: shared root account
On Tue, Jul 17, 2001 at 04:17:23AM -0800, Ethan Benson wrote: > On Tue, Jul 17, 2001 at 12:29:45PM +0100, Nick Phillips wrote: > > On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote: > > > > > nice to know pam_pwdfile gained md5 support, iirc it only did the > > > anchient crappy crypt before.. > > > > > > now there just needs to be a passwd command to work with this... > > > > htpasswd > > doesn't provide proper restrictions and authentication. (for other > uses then sudo passwords). > > whats really needed is a passwd command that behaves exactly the same > as passwd, only with alternate passwd files. Hmm, shouldn't some PAM-aware passwd implementation be able to do this? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Tue, Jul 17, 2001 at 12:29:45PM +0100, Nick Phillips wrote: > On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote: > > > nice to know pam_pwdfile gained md5 support, iirc it only did the > > anchient crappy crypt before.. > > > > now there just needs to be a passwd command to work with this... > > htpasswd doesn't provide proper restrictions and authentication. (for other uses then sudo passwords). whats really needed is a passwd command that behaves exactly the same as passwd, only with alternate passwd files. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpVOKL2WOz61.pgp Description: PGP signature
Re: shared root account
On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote: > nice to know pam_pwdfile gained md5 support, iirc it only did the > anchient crappy crypt before.. > > now there just needs to be a passwd command to work with this... htpasswd -- Nick Phillips -- [EMAIL PROTECTED] Don't feed the bats tonight.
Re: shared root account
On Tue, Jul 17, 2001 at 12:29:45PM +0100, Nick Phillips wrote: > On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote: > > > nice to know pam_pwdfile gained md5 support, iirc it only did the > > anchient crappy crypt before.. > > > > now there just needs to be a passwd command to work with this... > > htpasswd doesn't provide proper restrictions and authentication. (for other uses then sudo passwords). whats really needed is a passwd command that behaves exactly the same as passwd, only with alternate passwd files. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: shared root account
On Tue, Jul 10, 2001 at 05:29:32AM -0800, Ethan Benson wrote: > nice to know pam_pwdfile gained md5 support, iirc it only did the > anchient crappy crypt before.. > > now there just needs to be a passwd command to work with this... htpasswd -- Nick Phillips -- [EMAIL PROTECTED] Don't feed the bats tonight. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Tue, Jul 10, 2001 at 09:05:18AM -0400, Jason Healy wrote: > > At 994738826s since epoch (07/10/01 02:20:26 -0400 UTC), Micah Anderson wrote: > > These both seem like excellent practices, for the clueless in all of us - > > can someone describe how this is done for sudo? How do you configure PAM to > > require alternative passwords, which expire and age, and are decent > > passwords? And how does one reliably log sudo logs offsite? > > Please take a large grain of salt before reading, I haven't done this > stuff in a while so I'm rusty on it. I've included references to > where I've gotten the info so you can read more about it yourself. > > One can log to a different host by putting @hostname in your > syslog.conf file. I believe it looks like this: > > (`man syslog.conf`) > > auth,authpriv.* @log.myotherhost.com > > (assuming you have sudo logging at level auth) > > I know this may seem obvious, but make sure that this machine does not > share admin accounts with the machine you're logging from, or the > hacker will just break in and change the logs! > Don't forget, on the logging machine, syslog actually needs to be told to allow messages from the network (and listening, obviously). -r. [...] -- "... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed." - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, [EMAIL PROTECTED]
Re: shared root account
On Tue, Jul 10, 2001 at 09:05:18AM -0400, Jason Healy wrote: > > At 994738826s since epoch (07/10/01 02:20:26 -0400 UTC), Micah Anderson wrote: > > These both seem like excellent practices, for the clueless in all of us - > > can someone describe how this is done for sudo? How do you configure PAM to > > require alternative passwords, which expire and age, and are decent > > passwords? And how does one reliably log sudo logs offsite? > > Please take a large grain of salt before reading, I haven't done this > stuff in a while so I'm rusty on it. I've included references to > where I've gotten the info so you can read more about it yourself. > > One can log to a different host by putting @hostname in your > syslog.conf file. I believe it looks like this: > > (`man syslog.conf`) > > auth,authpriv.* @log.myotherhost.com > > (assuming you have sudo logging at level auth) > > I know this may seem obvious, but make sure that this machine does not > share admin accounts with the machine you're logging from, or the > hacker will just break in and change the logs! > Don't forget, on the logging machine, syslog actually needs to be told to allow messages from the network (and listening, obviously). -r. [...] -- "... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed." - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Tue, Jul 10, 2001 at 09:05:18AM -0400, Jason Healy wrote: > apt-get install libpam-doc libpam-opie libpam-pwdfile > > The first is docs, the second is OTP (one time passwords), and the > third is to authenticate against "passwd-like" files. The idea with > the third is that you make another passwd file (/etc/sudo.passwd), put > all your sudoers in it. Then, change /etc/pam.d/sudo to say: > > auth required /lib/security/pam_pwdfile.so pwdfile /etc/sudo.passwd you don't need to specify the full path to pam modules, and its better that you don't (debian pam policy). > Also, from that README: > > == >The ASCII password file is simply a list of lines, each looking like >this: >username:crypted_passwd[13] in the case of vanilla crypted passwords, >username:crypted_passwd[34] in the case of MD5 crypted passwords. > == nice to know pam_pwdfile gained md5 support, iirc it only did the anchient crappy crypt before.. now there just needs to be a passwd command to work with this... -- Ethan Benson http://www.alaska.net/~erbenson/ pgpNQ1kIobzyQ.pgp Description: PGP signature
Re: shared root account
At 994738826s since epoch (07/10/01 02:20:26 -0400 UTC), Micah Anderson wrote: > These both seem like excellent practices, for the clueless in all of us - > can someone describe how this is done for sudo? How do you configure PAM to > require alternative passwords, which expire and age, and are decent > passwords? And how does one reliably log sudo logs offsite? Please take a large grain of salt before reading, I haven't done this stuff in a while so I'm rusty on it. I've included references to where I've gotten the info so you can read more about it yourself. One can log to a different host by putting @hostname in your syslog.conf file. I believe it looks like this: (`man syslog.conf`) auth,authpriv.* @log.myotherhost.com (assuming you have sudo logging at level auth) I know this may seem obvious, but make sure that this machine does not share admin accounts with the machine you're logging from, or the hacker will just break in and change the logs! As for PAM fun, try the following: apt-get install libpam-doc libpam-opie libpam-pwdfile The first is docs, the second is OTP (one time passwords), and the third is to authenticate against "passwd-like" files. The idea with the third is that you make another passwd file (/etc/sudo.passwd), put all your sudoers in it. Then, change /etc/pam.d/sudo to say: auth required /lib/security/pam_pwdfile.so pwdfile /etc/sudo.passwd (`less /usr/doc/libpam-pwdfile/README`) Also, from that README: == The ASCII password file is simply a list of lines, each looking like this: username:crypted_passwd[13] in the case of vanilla crypted passwords, username:crypted_passwd[34] in the case of MD5 crypted passwords. == To do OTP instead, read /usr/doc/libpam-opie/README.Debian. A full discussion of OTP and how to set it up and use it is beyond the scope of this thread. Perhaps another thread would be good for that if people are interested. There are merits to be debated, and a whole other flamewar awaits that topic... =) Anyway, that's my first stab at it; others, please comment! I'm not sure if this is the best/right way to do it but I hope this gets things going. Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/
Re: shared root account
At 994740997s since epoch (07/10/01 03:56:37 -0400 UTC), Ethan Benson wrote: > detectability is the key here, the case should be locked shut ... > > compare this to your envolope idea where the machine need not even be > shutdown and tell me which is more likely to go by unnoticed. Okay, we've all drifted pretty far here. I was only describing one particular setup that we used. My point was to emphasize the use of sudo, and the fact that nobody knew the root password. There were specific circumstances that caused the use of the "envelope" system. As always, everyone has to weigh security against usability. Just so you know, the box in question was a student webserver at my college. It was run purely by students, and we had several admins. The machine lived in the college's machine room, which had door locks and an alarm system. If the students were away on vacation and the machine needed a reboot (or fsck, or whatever), the college IT staff could be paged in and use the envelope to get root on the box. It was *reasonable* to assume that nobody would break into the machine room without tripping the alarm system. It was *reasonable* to assume that the IT staff wouldn't go rooting our box for fun when we weren't around. Again, it all comes down to trust at one point or another. We could have welded the case shut and kept the root password in a fireproof safe with a hair-trigger self-destruct mechanism, but we're a student group, not the CIA. We make backups, and so the setup above gave us enough security to feel comfortable without driving everyone nuts. Same should go for everyone. If it's your company's payroll machine, then perhaps some of the other measures described are appropriate. If it's a public lab machine, then obviously sticking an envelope to it would be foolish. Each situation dictates different security measures. Anyway, like I said, my story was more about using sudo (that is, theoretically, what this thread is about), and less about how to implement physical security at any given location. That discussion is interesting, but bear in mind that physical security should be very closely tied to the environment. My story was just for illustration. Rock on, Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/
Re: shared root account
On Tue, Jul 10, 2001 at 09:05:18AM -0400, Jason Healy wrote: > apt-get install libpam-doc libpam-opie libpam-pwdfile > > The first is docs, the second is OTP (one time passwords), and the > third is to authenticate against "passwd-like" files. The idea with > the third is that you make another passwd file (/etc/sudo.passwd), put > all your sudoers in it. Then, change /etc/pam.d/sudo to say: > > auth required /lib/security/pam_pwdfile.so pwdfile /etc/sudo.passwd you don't need to specify the full path to pam modules, and its better that you don't (debian pam policy). > Also, from that README: > > == >The ASCII password file is simply a list of lines, each looking like >this: >username:crypted_passwd[13] in the case of vanilla crypted passwords, >username:crypted_passwd[34] in the case of MD5 crypted passwords. > == nice to know pam_pwdfile gained md5 support, iirc it only did the anchient crappy crypt before.. now there just needs to be a passwd command to work with this... -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: shared root account
At 994738826s since epoch (07/10/01 02:20:26 -0400 UTC), Micah Anderson wrote: > These both seem like excellent practices, for the clueless in all of us - > can someone describe how this is done for sudo? How do you configure PAM to > require alternative passwords, which expire and age, and are decent > passwords? And how does one reliably log sudo logs offsite? Please take a large grain of salt before reading, I haven't done this stuff in a while so I'm rusty on it. I've included references to where I've gotten the info so you can read more about it yourself. One can log to a different host by putting @hostname in your syslog.conf file. I believe it looks like this: (`man syslog.conf`) auth,authpriv.* @log.myotherhost.com (assuming you have sudo logging at level auth) I know this may seem obvious, but make sure that this machine does not share admin accounts with the machine you're logging from, or the hacker will just break in and change the logs! As for PAM fun, try the following: apt-get install libpam-doc libpam-opie libpam-pwdfile The first is docs, the second is OTP (one time passwords), and the third is to authenticate against "passwd-like" files. The idea with the third is that you make another passwd file (/etc/sudo.passwd), put all your sudoers in it. Then, change /etc/pam.d/sudo to say: auth required /lib/security/pam_pwdfile.so pwdfile /etc/sudo.passwd (`less /usr/doc/libpam-pwdfile/README`) Also, from that README: == The ASCII password file is simply a list of lines, each looking like this: username:crypted_passwd[13] in the case of vanilla crypted passwords, username:crypted_passwd[34] in the case of MD5 crypted passwords. == To do OTP instead, read /usr/doc/libpam-opie/README.Debian. A full discussion of OTP and how to set it up and use it is beyond the scope of this thread. Perhaps another thread would be good for that if people are interested. There are merits to be debated, and a whole other flamewar awaits that topic... =) Anyway, that's my first stab at it; others, please comment! I'm not sure if this is the best/right way to do it but I hope this gets things going. Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
At 994740997s since epoch (07/10/01 03:56:37 -0400 UTC), Ethan Benson wrote: > detectability is the key here, the case should be locked shut ... > > compare this to your envolope idea where the machine need not even be > shutdown and tell me which is more likely to go by unnoticed. Okay, we've all drifted pretty far here. I was only describing one particular setup that we used. My point was to emphasize the use of sudo, and the fact that nobody knew the root password. There were specific circumstances that caused the use of the "envelope" system. As always, everyone has to weigh security against usability. Just so you know, the box in question was a student webserver at my college. It was run purely by students, and we had several admins. The machine lived in the college's machine room, which had door locks and an alarm system. If the students were away on vacation and the machine needed a reboot (or fsck, or whatever), the college IT staff could be paged in and use the envelope to get root on the box. It was *reasonable* to assume that nobody would break into the machine room without tripping the alarm system. It was *reasonable* to assume that the IT staff wouldn't go rooting our box for fun when we weren't around. Again, it all comes down to trust at one point or another. We could have welded the case shut and kept the root password in a fireproof safe with a hair-trigger self-destruct mechanism, but we're a student group, not the CIA. We make backups, and so the setup above gave us enough security to feel comfortable without driving everyone nuts. Same should go for everyone. If it's your company's payroll machine, then perhaps some of the other measures described are appropriate. If it's a public lab machine, then obviously sticking an envelope to it would be foolish. Each situation dictates different security measures. Anyway, like I said, my story was more about using sudo (that is, theoretically, what this thread is about), and less about how to implement physical security at any given location. That discussion is interesting, but bear in mind that physical security should be very closely tied to the environment. My story was just for illustration. Rock on, Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Mon, Jul 09, 2001 at 08:38:56PM -0500, Martin Maney wrote: > > Give me physical access and I don't need your root password, though it may > help make the job less detectable. But you don't get more security than you > physically have to begin with. detectability is the key here, the case should be locked shut, bootloader put into restricted mode (no special args without password), and firmware protected to only boot from the specific disk. when you do all of this the machine will HAVE to be shutdown and physically broken open. the shutdown alone should cause you to perform a thorough audit (especially when you find the case broken and cut open...). compare this to your envolope idea where the machine need not even be shutdown and tell me which is more likely to go by unnoticed. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpzrTKKDWLMY.pgp Description: PGP signature
Re: shared root account
On Mon, 09 Jul 2001, Jason Healy wrote: > About the best you can hope for is to log to another machine (so > sudoers can't hose your logfiles), and be vigilant about checking what > they do. > > Anyway, to your point about passwords, I say again (do we detect a > theme?): use PAM and make them use a different password for sudo. If > you want to get real draconian, you can make them use OTP (one-time These both seem like excellent practices, for the clueless in all of us - can someone describe how this is done for sudo? How do you configure PAM to require alternative passwords, which expire and age, and are decent passwords? And how does one reliably log sudo logs offsite? Micah
Re: shared root account
On Mon, Jul 09, 2001 at 08:38:56PM -0500, Martin Maney wrote: > > Give me physical access and I don't need your root password, though it may > help make the job less detectable. But you don't get more security than you > physically have to begin with. detectability is the key here, the case should be locked shut, bootloader put into restricted mode (no special args without password), and firmware protected to only boot from the specific disk. when you do all of this the machine will HAVE to be shutdown and physically broken open. the shutdown alone should cause you to perform a thorough audit (especially when you find the case broken and cut open...). compare this to your envolope idea where the machine need not even be shutdown and tell me which is more likely to go by unnoticed. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: shared root account
On Mon, 09 Jul 2001, Jason Healy wrote: > About the best you can hope for is to log to another machine (so > sudoers can't hose your logfiles), and be vigilant about checking what > they do. > > Anyway, to your point about passwords, I say again (do we detect a > theme?): use PAM and make them use a different password for sudo. If > you want to get real draconian, you can make them use OTP (one-time These both seem like excellent practices, for the clueless in all of us - can someone describe how this is done for sudo? How do you configure PAM to require alternative passwords, which expire and age, and are decent passwords? And how does one reliably log sudo logs offsite? Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Mon, Jul 09, 2001 at 04:18:10PM -0800, Ethan Benson wrote: > On Mon, Jul 09, 2001 at 09:33:12AM -0400, Jason Healy wrote: > > machine. The machine was locked in the server room, so the only > > people who could get to the root password (and the console) were the > > people with keys. If you needed to boot to single-user, you'd rip > > which in most places includes janitors and low paid rent-a-cops. Give me physical access and I don't need your root password, though it may help make the job less detectable. But you don't get more security than you physically have to begin with. > nice way to root a box without being detected, just bring along a new > envelope and nobody will be the wiser. Except the admin who put that password into the envelope. That was one thing that seemed off in the original description, but maybe the proecess was just glossed over and the new password really is somehow installed and put on paper and into the envelope without any way for the admin who used the old one to find out what it is. Color me dubious, though. -- Neither can his mind be in tune, whose words do jarre, nor his reason in frame, whose sentence is preposterous. -- Ben Jonson
Re: shared root account
On Mon, Jul 09, 2001 at 09:33:12AM -0400, Jason Healy wrote: > > Our solution to this (multiple admins on a single box) was to write > the root password (some horribly cryptic thing) down on a piece of > paper and put it in a sealed envelope, which we then stuck to the > machine. The machine was locked in the server room, so the only > people who could get to the root password (and the console) were the > people with keys. If you needed to boot to single-user, you'd rip which in most places includes janitors and low paid rent-a-cops. > open the envelope and use the password. When you were done, you'd > change the password, write it down on a new piece of paper, and seal > in in an evelope. nice way to root a box without being detected, just bring along a new envelope and nobody will be the wiser. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpMaREpynxoH.pgp Description: PGP signature
Re: shared root account
from `man zsh`: Alias expansion is done on the shell input before any other expansion except history expansion. Therefore, if an alias is defined for the word foo, alias expansion may be avoided by quoting part of the word, e.g. \foo. But there is nothing to prevent an alias being defined for \foo as well. Boo, zsh, boo. Vineet * Tim Haynes ([EMAIL PROTECTED]) [010709 15:44]: > <[EMAIL PROTECTED]> writes: > > > On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote: > > > > > Note that > > > alias '\/bin/su'="echo eek" > > > > > > comments accordingly on one's ability to bypass *that*, too. > > > > > > Woops. :) > > > > Have you tried it? :-) At least with my version of bash > > (2.05.0(1)-release) it won't do it. Or rather it'll take the alias, but I > > don't believe anything will ever match it. I tried it before I sent it > > with alias \\/bin/su, just to be sure. > > Yes, I tried it, but I guess my zsh differs from your bash. Oh well. :) > > ~Tim > -- > 20:38:08 up 1 day, 6:35, 11 users, load average: 0.03, 0.01, 0.00 > [EMAIL PROTECTED] |We stood in the moonlight > http://piglet.is.dreaming.org |and the river flowed > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > pgpjmHZK4NWn5.pgp Description: PGP signature
Re: shared root account
On Mon, Jul 09, 2001 at 04:18:10PM -0800, Ethan Benson wrote: > On Mon, Jul 09, 2001 at 09:33:12AM -0400, Jason Healy wrote: > > machine. The machine was locked in the server room, so the only > > people who could get to the root password (and the console) were the > > people with keys. If you needed to boot to single-user, you'd rip > > which in most places includes janitors and low paid rent-a-cops. Give me physical access and I don't need your root password, though it may help make the job less detectable. But you don't get more security than you physically have to begin with. > nice way to root a box without being detected, just bring along a new > envelope and nobody will be the wiser. Except the admin who put that password into the envelope. That was one thing that seemed off in the original description, but maybe the proecess was just glossed over and the new password really is somehow installed and put on paper and into the envelope without any way for the admin who used the old one to find out what it is. Color me dubious, though. -- Neither can his mind be in tune, whose words do jarre, nor his reason in frame, whose sentence is preposterous. -- Ben Jonson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > "Jason" == Jason Healy <[EMAIL PROTECTED]> writes: Jason> Our solution to this (multiple admins on a single box) was to Jason> write the root password (some horribly cryptic thing) down on a Jason> piece of paper and put it in a sealed envelope, which we then Jason> stuck to the machine. The machine was locked in the server room, Jason> so the only people who could get to the root password (and the Jason> console) were the people with keys. If you needed to boot to Jason> single-user, you'd rip open the envelope and use the password. Jason> When you were done, you'd change the password, write it down on a Jason> new piece of paper, and seal in in an evelope. Even better would be to keep the password in a locked box and give the admins keys to the box. And you might want to have the admins sign across the seal of the envelope, so that you'll know if someone broke in, did something nasty, and replaced the password. - -- Hubert Chan <[EMAIL PROTECTED]> - http://www.geocities.com/hubertchan/ PGP/GnuPG key: 1024D/71FDA37F Fingerprint: 6CC5 822D 2E55 494C 81DD 6F2C 6518 54DF 71FD A37F Key available at wwwkeys.pgp.net. Please encrypt *all* e-mail to me. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SgO1ZRhU33H9o38RAm/iAJ9VDMkK3F60ETOyfX01va4XeyEjkwCfQDvj DY2SprWlpIhkdnEAVPldm+4= =RZG/ -END PGP SIGNATURE-
Re: shared root account
On Mon, Jul 09, 2001 at 09:33:12AM -0400, Jason Healy wrote: > > Our solution to this (multiple admins on a single box) was to write > the root password (some horribly cryptic thing) down on a piece of > paper and put it in a sealed envelope, which we then stuck to the > machine. The machine was locked in the server room, so the only > people who could get to the root password (and the console) were the > people with keys. If you needed to boot to single-user, you'd rip which in most places includes janitors and low paid rent-a-cops. > open the envelope and use the password. When you were done, you'd > change the password, write it down on a new piece of paper, and seal > in in an evelope. nice way to root a box without being detected, just bring along a new envelope and nobody will be the wiser. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: shared root account
<[EMAIL PROTECTED]> writes: > On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote: > > > Note that > > alias '\/bin/su'="echo eek" > > > > comments accordingly on one's ability to bypass *that*, too. > > > > Woops. :) > > Have you tried it? :-) At least with my version of bash > (2.05.0(1)-release) it won't do it. Or rather it'll take the alias, but I > don't believe anything will ever match it. I tried it before I sent it > with alias \\/bin/su, just to be sure. Yes, I tried it, but I guess my zsh differs from your bash. Oh well. :) ~Tim -- 20:38:08 up 1 day, 6:35, 11 users, load average: 0.03, 0.01, 0.00 [EMAIL PROTECTED] |We stood in the moonlight http://piglet.is.dreaming.org |and the river flowed
Re: shared root account
from `man zsh`: Alias expansion is done on the shell input before any other expansion except history expansion. Therefore, if an alias is defined for the word foo, alias expansion may be avoided by quoting part of the word, e.g. \foo. But there is nothing to prevent an alias being defined for \foo as well. Boo, zsh, boo. Vineet * Tim Haynes ([EMAIL PROTECTED]) [010709 15:44]: > <[EMAIL PROTECTED]> writes: > > > On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote: > > > > > Note that > > > alias '\/bin/su'="echo eek" > > > > > > comments accordingly on one's ability to bypass *that*, too. > > > > > > Woops. :) > > > > Have you tried it? :-) At least with my version of bash > > (2.05.0(1)-release) it won't do it. Or rather it'll take the alias, but I > > don't believe anything will ever match it. I tried it before I sent it > > with alias \\/bin/su, just to be sure. > > Yes, I tried it, but I guess my zsh differs from your bash. Oh well. :) > > ~Tim > -- > 20:38:08 up 1 day, 6:35, 11 users, load average: 0.03, 0.01, 0.00 > [EMAIL PROTECTED] |We stood in the moonlight > http://piglet.is.dreaming.org |and the river flowed > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > PGP signature
Re: shared root account
On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote: > Note that > alias '\/bin/su'="echo eek" > > comments accordingly on one's ability to bypass *that*, too. > > Woops. :) Have you tried it? :-) At least with my version of bash (2.05.0(1)-release) it won't do it. Or rather it'll take the alias, but I don't believe anything will ever match it. I tried it before I sent it with alias \\/bin/su, just to be sure. Bob
Re: shared root account
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > "Jason" == Jason Healy <[EMAIL PROTECTED]> writes: Jason> Our solution to this (multiple admins on a single box) was to Jason> write the root password (some horribly cryptic thing) down on a Jason> piece of paper and put it in a sealed envelope, which we then Jason> stuck to the machine. The machine was locked in the server room, Jason> so the only people who could get to the root password (and the Jason> console) were the people with keys. If you needed to boot to Jason> single-user, you'd rip open the envelope and use the password. Jason> When you were done, you'd change the password, write it down on a Jason> new piece of paper, and seal in in an evelope. Even better would be to keep the password in a locked box and give the admins keys to the box. And you might want to have the admins sign across the seal of the envelope, so that you'll know if someone broke in, did something nasty, and replaced the password. - -- Hubert Chan <[EMAIL PROTECTED]> - http://www.geocities.com/hubertchan/ PGP/GnuPG key: 1024D/71FDA37F Fingerprint: 6CC5 822D 2E55 494C 81DD 6F2C 6518 54DF 71FD A37F Key available at wwwkeys.pgp.net. Please encrypt *all* e-mail to me. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7SgO1ZRhU33H9o38RAm/iAJ9VDMkK3F60ETOyfX01va4XeyEjkwCfQDvj DY2SprWlpIhkdnEAVPldm+4= =RZG/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
<[EMAIL PROTECTED]> writes: > > > alias /bin/su='/var/tmp/hax0rSu' > > > > i would consider this a bug in the shell. > > Note that \/bin/su would avoid the alias. Note that alias '\/bin/su'="echo eek" comments accordingly on one's ability to bypass *that*, too. Woops. :) ~Tim -- 8:22pm up 2 days, 23:31, 5 users, load average: 0.21, 0.28, 0.36 [EMAIL PROTECTED] |As long as I can see the morning http://piglet.is.dreaming.org |And blossom turns to bud again in spring
Re: shared root account
<[EMAIL PROTECTED]> writes: > On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote: > > > Note that > > alias '\/bin/su'="echo eek" > > > > comments accordingly on one's ability to bypass *that*, too. > > > > Woops. :) > > Have you tried it? :-) At least with my version of bash > (2.05.0(1)-release) it won't do it. Or rather it'll take the alias, but I > don't believe anything will ever match it. I tried it before I sent it > with alias \\/bin/su, just to be sure. Yes, I tried it, but I guess my zsh differs from your bash. Oh well. :) ~Tim -- 20:38:08 up 1 day, 6:35, 11 users, load average: 0.03, 0.01, 0.00 [EMAIL PROTECTED] |We stood in the moonlight http://piglet.is.dreaming.org |and the river flowed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote: > On Sat, Jul 07, 2001 at 10:31:56AM +, Jim Breton wrote: > > On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote: > > > which may not work if you always type the > > > full path to /bin/su anyway. > > > > Hoping he doesn't: > > > > alias /bin/su='/var/tmp/hax0rSu' > > i would consider this a bug in the shell. Note that \/bin/su would avoid the alias. Bob
Re: shared root account
On Mon, Jul 09, 2001 at 08:23:43PM +0100, Tim Haynes wrote: > Note that > alias '\/bin/su'="echo eek" > > comments accordingly on one's ability to bypass *that*, too. > > Woops. :) Have you tried it? :-) At least with my version of bash (2.05.0(1)-release) it won't do it. Or rather it'll take the alias, but I don't believe anything will ever match it. I tried it before I sent it with alias \\/bin/su, just to be sure. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
<[EMAIL PROTECTED]> writes: > > > alias /bin/su='/var/tmp/hax0rSu' > > > > i would consider this a bug in the shell. > > Note that \/bin/su would avoid the alias. Note that alias '\/bin/su'="echo eek" comments accordingly on one's ability to bypass *that*, too. Woops. :) ~Tim -- 8:22pm up 2 days, 23:31, 5 users, load average: 0.21, 0.28, 0.36 [EMAIL PROTECTED] |As long as I can see the morning http://piglet.is.dreaming.org |And blossom turns to bud again in spring -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote: > On Sat, Jul 07, 2001 at 10:31:56AM +, Jim Breton wrote: > > On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote: > > > which may not work if you always type the > > > full path to /bin/su anyway. > > > > Hoping he doesn't: > > > > alias /bin/su='/var/tmp/hax0rSu' > > i would consider this a bug in the shell. Note that \/bin/su would avoid the alias. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
As far as trusting their password choices, I'm not too worried about password guessing attacks; if an admin gets a password past pam_cracklib.so (without overriding it as root), I have doubts that someone's going to guess the password. Admins using the same password for multiple accounts is another problem entirely; I don't have an answer for this, unfortunately, other than a) making it company policy to use different passwords on different machines, or b) as others have suggested, using pam to use one-time passwords or something. As far as trusting admins with their actions, this is the same whether or not you're using a shared root account, or sudo. If the admin is ssh'ing in from home, on a compromised windows box, and using any type of root function, the attacker now has the capability to do the same. If you're worried about this sort of thing, again, policy is the most effective technique. Set up a firewall (that the admins don't have access to), so that admins may only ssh into high security boxes while physically at work. If using windows, have workstations reinstalled frequently, and disallow installation of third party software. Or even better, don't use windows. ;) If using some form of unix, use an internal company distro (modified popular distro w/ extra needed software, perhaps logging of md5sums or logs to a central server). I could list a million other things you can do, but basically just ensure that admins are _probably_ originating from a secured machine. At least w/ sudo, if a password gets out (and syslog is logging somewhere besides localhst), you can see which account the breakin originated from, and take appropriate action. On Mon, Jul 09, 2001 at 08:00:14AM -0700, Micah Anderson wrote: [...] > Having said that we do it this way as well, I'll point out one flaw which > particularly nags at me. Andreas said, "a) allowing convenience by allowing > the user to effectively choose their own root passwd." which roughly > equivicates to the difference between having one root password that can be > cracked to get to the system, to having N+1 root passwords that can be > cracked to get at the system (where N=number of admins with sudo access). At > this point it is a toss up - is the convenience of not having to pass around > the root password to all the admins worth the additional cracks? Do you > trust each admin to be secure with both their password choices as well as > the rest of their actions? > > Micah > -- "... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed." - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, [EMAIL PROTECTED]
Re: shared root account
At 994683614s since epoch (07/09/01 11:00:14 -0400 UTC), Micah Anderson wrote: > Having said that we do it this way as well, I'll point out one flaw which > particularly nags at me. Andreas said, "a) allowing convenience by allowing > the user to effectively choose their own root passwd." which roughly > equivicates to the difference between having one root password that can be > cracked to get to the system, to having N+1 root passwords that can be > cracked to get at the system (where N=number of admins with sudo access). At > this point it is a toss up - is the convenience of not having to pass around > the root password to all the admins worth the additional cracks? Do you > trust each admin to be secure with both their password choices as well as > the rest of their actions? Two things here. First, if you don't trust your admins, then you've got problems. If they don't need to do much, you can always just write them custom software (for example, if the admins only need to change passwords, just give them an suid password-changing script). But if they need to do a fair amount, then you're just going to have to trust them at some point. It's hard enough to keep regular users from getting root; keeping admins from doing it is just insanity. About the best you can hope for is to log to another machine (so sudoers can't hose your logfiles), and be vigilant about checking what they do. Anyway, to your point about passwords, I say again (do we detect a theme?): use PAM and make them use a different password for sudo. If you want to get real draconian, you can make them use OTP (one-time passwords). This isn't the greatest idea, though, because it encourages the use of 'sudo -s' to avoid password hassles. Barring that, however, you can make them use a different password from their login. Assuming they use ssh and not telnet (they DO use ssh, right???), a comprimise of the first doesn't lead to an immediate comprimise of the second. Yes, clever hackers will insert trojans to sniff that second password, but there are ways around that (OTP, anyone??). As usual, this will boil down to the big Theory vs Practice argument. In theory, sudo shouldn't let peple break out of their little semi-root cage, and you should be able to not totally trust your admins. But alas, this isn't so. You'll have to do the best you can with sudo, log like crazy, and apply The Smack to anyone who "plays" with sudo too much. Combine this with a strong policy of ssh, good passwords, and sudo policy (separate passwords, time restrictions, command restrictions), and I think you're doing the best you can. And, like I said, it's better than plain 'ol su, no matter how you slice it. Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/
Re: shared root account
I agree with this assessment of Andreas' - in fact this is what we use in our organization. Unfortunately we don't have the luxury of fully trusting admins, so I am a little paranoid about giving out full-on sudo to people, but this is mostly a personnel issue having to do with the nature of the industry with which our organization operates. Having said that we do it this way as well, I'll point out one flaw which particularly nags at me. Andreas said, "a) allowing convenience by allowing the user to effectively choose their own root passwd." which roughly equivicates to the difference between having one root password that can be cracked to get to the system, to having N+1 root passwords that can be cracked to get at the system (where N=number of admins with sudo access). At this point it is a toss up - is the convenience of not having to pass around the root password to all the admins worth the additional cracks? Do you trust each admin to be secure with both their password choices as well as the rest of their actions? Micah On Sun, 08 Jul 2001, Andres Salomon wrote: > This is completely off-topic at this point, but there are a few uses > of sudo. The original poster trusts his admins, and wants to give > them all root privs without the hassle of having them all use one > account. Sudo is not enforcing anything in this case, it is merely > a) allowing convenience by allowing the user to effectively choose > their own root passwd. > b) allowing a form of audit trail; true, it's easy enough to bypass, > but someone trusted wouldn't go out of their way to bypass it. It's > good for when (for example) samba suddenly stops working, instead of > checking /root/.bash_history for " /etc/smb.conf", running > `last` to see when root has logged in since it broke, etc etc, > you simply check your logs for the last time someone sudo'd " > smb.conf". Make it policy for admins to not use `sudo bash`, or > anything similar. > > What you people are talking about is adding privs to an untrusted > account. The (ridiculous) example given, of allowing a user to > run /bin/cat, is similar doing a `chown root: /bin/cat; > chmod 4770 /bin/cat`. It's dangerous. What a _sane_ admin would do, > if the user needed to view a file, is provide the argument to cat that > was required. " ALL=(root) /bin/cat /etc/[a-zA-Z]". Or > specify the exact filename. If it's an untrusted user, they should > be given as little leeway as possible. Allowing them to cat any file > on the system is just stupid. > > On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: > > Resent-Date: Fri, 06 Jul 2001 21:11:34 -0400 > > > > > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: > > > > Ethan> or even seemingly innocuous things like less or even cat. > > > > Less is a problem, yes, as is anything else with a shell escape. > > > > Ethan> sudo less anything !/bin/sh whoami r00t! > > > > Ethan> echo me ALL=ALL > s sudo 'cat s >> /etc/sudoers' > > > > doesn't work. the >> is a shell redirection, but sudo doesn't > > evaluate in a shell. > > > > $ echo me ALL=ALL > s > > $ cat s > > me ALL=ALL > > $ sudo 'cat s > foo' > > sudo: cat s > foo: command not found > > $ sudo cat s \> foo > > me ALL=ALL > > cat: >: No such file or directory > > cat: foo: No such file or directory > > > > I would be very shocked if you could compromise a system with a > > sudoers entry of: > > me hostname = (root) /bin/cat > > > > Ethan> sudo is a very large cannon which is difficult to keep aimed > > Ethan> away from the foot... > > > > That it is. But then, the root password is basically a very large > > cannon built into your shoe. > > > > -Eric > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > > -- > "... being a Linux user is sort of like living in a house inhabited > by a large family of carpenters and architects. Every morning when > you wake up, the house is a little different. Maybe there is a new > turret, or some walls have moved. Or perhaps someone has temporarily > removed the floor under your bed." - Unix for Dummies, 2nd Edition > -- found in the .sig of Rob Riggs, [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
At 994696370s since epoch (07/09/01 04:32:50 -0400 UTC), Juha J?ykk? wrote: > One question raises however: If I have multiple uid=0 accounts, > will any of their passwords suffice as "root" password when entering > single user mode? Obviously sudo will not do here, so I will need a > root password, period. Our solution to this (multiple admins on a single box) was to write the root password (some horribly cryptic thing) down on a piece of paper and put it in a sealed envelope, which we then stuck to the machine. The machine was locked in the server room, so the only people who could get to the root password (and the console) were the people with keys. If you needed to boot to single-user, you'd rip open the envelope and use the password. When you were done, you'd change the password, write it down on a new piece of paper, and seal in in an evelope. The rest of the time, all admins used sudo. Nobody ever "knew" the root password. > The other users will have to make do with either > sudo or multiple uid=0 accounts. Multiple uid=0 accounts sounds better > in that it does not elevate ordinary passwords into root passwords (of > course, in practice people may keep them the same - can that be > helped?) but on the other hand, sudo would log... Just a reminder, you can configure sudo to use a different password from the regular user account (through PAM). That alternate password could be checked to ensure that it was strong and didn't match the user's password if you really wanted. Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/
Re: shared root account
As far as trusting their password choices, I'm not too worried about password guessing attacks; if an admin gets a password past pam_cracklib.so (without overriding it as root), I have doubts that someone's going to guess the password. Admins using the same password for multiple accounts is another problem entirely; I don't have an answer for this, unfortunately, other than a) making it company policy to use different passwords on different machines, or b) as others have suggested, using pam to use one-time passwords or something. As far as trusting admins with their actions, this is the same whether or not you're using a shared root account, or sudo. If the admin is ssh'ing in from home, on a compromised windows box, and using any type of root function, the attacker now has the capability to do the same. If you're worried about this sort of thing, again, policy is the most effective technique. Set up a firewall (that the admins don't have access to), so that admins may only ssh into high security boxes while physically at work. If using windows, have workstations reinstalled frequently, and disallow installation of third party software. Or even better, don't use windows. ;) If using some form of unix, use an internal company distro (modified popular distro w/ extra needed software, perhaps logging of md5sums or logs to a central server). I could list a million other things you can do, but basically just ensure that admins are _probably_ originating from a secured machine. At least w/ sudo, if a password gets out (and syslog is logging somewhere besides localhst), you can see which account the breakin originated from, and take appropriate action. On Mon, Jul 09, 2001 at 08:00:14AM -0700, Micah Anderson wrote: [...] > Having said that we do it this way as well, I'll point out one flaw which > particularly nags at me. Andreas said, "a) allowing convenience by allowing > the user to effectively choose their own root passwd." which roughly > equivicates to the difference between having one root password that can be > cracked to get to the system, to having N+1 root passwords that can be > cracked to get at the system (where N=number of admins with sudo access). At > this point it is a toss up - is the convenience of not having to pass around > the root password to all the admins worth the additional cracks? Do you > trust each admin to be secure with both their password choices as well as > the rest of their actions? > > Micah > -- "... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed." - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
At 994683614s since epoch (07/09/01 11:00:14 -0400 UTC), Micah Anderson wrote: > Having said that we do it this way as well, I'll point out one flaw which > particularly nags at me. Andreas said, "a) allowing convenience by allowing > the user to effectively choose their own root passwd." which roughly > equivicates to the difference between having one root password that can be > cracked to get to the system, to having N+1 root passwords that can be > cracked to get at the system (where N=number of admins with sudo access). At > this point it is a toss up - is the convenience of not having to pass around > the root password to all the admins worth the additional cracks? Do you > trust each admin to be secure with both their password choices as well as > the rest of their actions? Two things here. First, if you don't trust your admins, then you've got problems. If they don't need to do much, you can always just write them custom software (for example, if the admins only need to change passwords, just give them an suid password-changing script). But if they need to do a fair amount, then you're just going to have to trust them at some point. It's hard enough to keep regular users from getting root; keeping admins from doing it is just insanity. About the best you can hope for is to log to another machine (so sudoers can't hose your logfiles), and be vigilant about checking what they do. Anyway, to your point about passwords, I say again (do we detect a theme?): use PAM and make them use a different password for sudo. If you want to get real draconian, you can make them use OTP (one-time passwords). This isn't the greatest idea, though, because it encourages the use of 'sudo -s' to avoid password hassles. Barring that, however, you can make them use a different password from their login. Assuming they use ssh and not telnet (they DO use ssh, right???), a comprimise of the first doesn't lead to an immediate comprimise of the second. Yes, clever hackers will insert trojans to sniff that second password, but there are ways around that (OTP, anyone??). As usual, this will boil down to the big Theory vs Practice argument. In theory, sudo shouldn't let peple break out of their little semi-root cage, and you should be able to not totally trust your admins. But alas, this isn't so. You'll have to do the best you can with sudo, log like crazy, and apply The Smack to anyone who "plays" with sudo too much. Combine this with a strong policy of ssh, good passwords, and sudo policy (separate passwords, time restrictions, command restrictions), and I think you're doing the best you can. And, like I said, it's better than plain 'ol su, no matter how you slice it. Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
I agree with this assessment of Andreas' - in fact this is what we use in our organization. Unfortunately we don't have the luxury of fully trusting admins, so I am a little paranoid about giving out full-on sudo to people, but this is mostly a personnel issue having to do with the nature of the industry with which our organization operates. Having said that we do it this way as well, I'll point out one flaw which particularly nags at me. Andreas said, "a) allowing convenience by allowing the user to effectively choose their own root passwd." which roughly equivicates to the difference between having one root password that can be cracked to get to the system, to having N+1 root passwords that can be cracked to get at the system (where N=number of admins with sudo access). At this point it is a toss up - is the convenience of not having to pass around the root password to all the admins worth the additional cracks? Do you trust each admin to be secure with both their password choices as well as the rest of their actions? Micah On Sun, 08 Jul 2001, Andres Salomon wrote: > This is completely off-topic at this point, but there are a few uses > of sudo. The original poster trusts his admins, and wants to give > them all root privs without the hassle of having them all use one > account. Sudo is not enforcing anything in this case, it is merely > a) allowing convenience by allowing the user to effectively choose > their own root passwd. > b) allowing a form of audit trail; true, it's easy enough to bypass, > but someone trusted wouldn't go out of their way to bypass it. It's > good for when (for example) samba suddenly stops working, instead of > checking /root/.bash_history for " /etc/smb.conf", running > `last` to see when root has logged in since it broke, etc etc, > you simply check your logs for the last time someone sudo'd " > smb.conf". Make it policy for admins to not use `sudo bash`, or > anything similar. > > What you people are talking about is adding privs to an untrusted > account. The (ridiculous) example given, of allowing a user to > run /bin/cat, is similar doing a `chown root: /bin/cat; > chmod 4770 /bin/cat`. It's dangerous. What a _sane_ admin would do, > if the user needed to view a file, is provide the argument to cat that > was required. " ALL=(root) /bin/cat /etc/[a-zA-Z]". Or > specify the exact filename. If it's an untrusted user, they should > be given as little leeway as possible. Allowing them to cat any file > on the system is just stupid. > > On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: > > Resent-Date: Fri, 06 Jul 2001 21:11:34 -0400 > > > > > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: > > > > Ethan> or even seemingly innocuous things like less or even cat. > > > > Less is a problem, yes, as is anything else with a shell escape. > > > > Ethan> sudo less anything !/bin/sh whoami r00t! > > > > Ethan> echo me ALL=ALL > s sudo 'cat s >> /etc/sudoers' > > > > doesn't work. the >> is a shell redirection, but sudo doesn't > > evaluate in a shell. > > > > $ echo me ALL=ALL > s > > $ cat s > > me ALL=ALL > > $ sudo 'cat s > foo' > > sudo: cat s > foo: command not found > > $ sudo cat s \> foo > > me ALL=ALL > > cat: >: No such file or directory > > cat: foo: No such file or directory > > > > I would be very shocked if you could compromise a system with a > > sudoers entry of: > > me hostname = (root) /bin/cat > > > > Ethan> sudo is a very large cannon which is difficult to keep aimed > > Ethan> away from the foot... > > > > That it is. But then, the root password is basically a very large > > cannon built into your shoe. > > > > -Eric > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > > -- > "... being a Linux user is sort of like living in a house inhabited > by a large family of carpenters and architects. Every morning when > you wake up, the house is a little different. Maybe there is a new > turret, or some walls have moved. Or perhaps someone has temporarily > removed the floor under your bed." - Unix for Dummies, 2nd Edition > -- found in the .sig of Rob Riggs, [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
At 994696370s since epoch (07/09/01 04:32:50 -0400 UTC), Juha J?ykk? wrote: > One question raises however: If I have multiple uid=0 accounts, > will any of their passwords suffice as "root" password when entering > single user mode? Obviously sudo will not do here, so I will need a > root password, period. Our solution to this (multiple admins on a single box) was to write the root password (some horribly cryptic thing) down on a piece of paper and put it in a sealed envelope, which we then stuck to the machine. The machine was locked in the server room, so the only people who could get to the root password (and the console) were the people with keys. If you needed to boot to single-user, you'd rip open the envelope and use the password. When you were done, you'd change the password, write it down on a new piece of paper, and seal in in an evelope. The rest of the time, all admins used sudo. Nobody ever "knew" the root password. > The other users will have to make do with either > sudo or multiple uid=0 accounts. Multiple uid=0 accounts sounds better > in that it does not elevate ordinary passwords into root passwords (of > course, in practice people may keep them the same - can that be > helped?) but on the other hand, sudo would log... Just a reminder, you can configure sudo to use a different password from the regular user account (through PAM). That alternate password could be checked to ensure that it was strong and didn't match the user's password if you really wanted. Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
Nice little storm of a chain I managed to start here... Quite off the original topic, mainly, where I trust the users. Many good points have been noted and basically all of them have been argued both pro and con. I will do a little summary here: 1) Some people like sudo, some think it is not secure enough. In my situation, where I am not worried about legitimate users trying to get elevated privileges, this might just work. On the other hand, the point that sudo elevates ordinary users' passwords into root passwords obviously makes it easier for an illegitimate user to gain root - it suffices to gain any sudoer's password and then employing any of the methods mentioned here to gain root with sudo regardless of the permissions allowed to that users by sudo. Solution to that would be expiring passwords and installing some password sanity checker - that way at least the users' passwords ought to be fairly good and new, i.e. hard to crack. Of course if someone cracks user A, who is NOT a sudoer and attempts to sudo, we get log entries and even if A IS a sudoer, but the culprit has simply managed to spawn A's shell and is trying to sudo, we get log entries. No use of sudo's logging, as noted earlier, if the attacker really has the password of a sudoer: logs can be cleaned unless they are a) sent to another, secure, machine or b) they are written to a write-once medium (anyone logging onto paper or CD, for example? - grepping a paper ought to be ... fun?). 2) A few people like ssh RSA-auth. Good idea. But I may (will) need access to these machines in situations when there is no network, i.e. running manual fsck's after a power failure. No way of ssh'ing into the box at that time. I will need the root password anyway. 3) A few people would create additional uid=0 accounts. Since my situation is akin to one with multiple admins trusting each other (more exactly - it's _they_ who are trusting _me_, not the other way around), this might be a good idea. No one would have to get familiar with sudo (I know that would cause some resistance - it would be viewed as something they do not need to get accustomed to) and I would get my root. Of course, sudo would give me nice logs of what the others have done - which is quite important if I am to keep the boxes secure: not knowing what's been changed makes that pretty hard. This is my option number 2 anyway, if people resist learning to type 'sudo' instead of logging in as root or saying 'su'. 4) Someone also noted that having linux workstations in the first place is a bad idea due the X's flawed security but I do not seem to remember any way of popping up windows on someone else's display when X server is properly configured (i.e. only to accept connections from localhost with a proper MIT secret cookie (or other auth mechanism). As I said above, in my situation, sudo is very appealing: keeping root password to myself and letting the workstation users sudo (or vice versa). One question raises however: If I have multiple uid=0 accounts, will any of their passwords suffice as "root" password when entering single user mode? Obviously sudo will not do here, so I will need a root password, period. The other users will have to make do with either sudo or multiple uid=0 accounts. Multiple uid=0 accounts sounds better in that it does not elevate ordinary passwords into root passwords (of course, in practice people may keep them the same - can that be helped?) but on the other hand, sudo would log... I will have to see how much use of their root accounts these people really make. Although many of the replies did not answer my question at all, some of them had good points, thanks to those. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: shared root account
Nice little storm of a chain I managed to start here... Quite off the original topic, mainly, where I trust the users. Many good points have been noted and basically all of them have been argued both pro and con. I will do a little summary here: 1) Some people like sudo, some think it is not secure enough. In my situation, where I am not worried about legitimate users trying to get elevated privileges, this might just work. On the other hand, the point that sudo elevates ordinary users' passwords into root passwords obviously makes it easier for an illegitimate user to gain root - it suffices to gain any sudoer's password and then employing any of the methods mentioned here to gain root with sudo regardless of the permissions allowed to that users by sudo. Solution to that would be expiring passwords and installing some password sanity checker - that way at least the users' passwords ought to be fairly good and new, i.e. hard to crack. Of course if someone cracks user A, who is NOT a sudoer and attempts to sudo, we get log entries and even if A IS a sudoer, but the culprit has simply managed to spawn A's shell and is trying to sudo, we get log entries. No use of sudo's logging, as noted earlier, if the attacker really has the password of a sudoer: logs can be cleaned unless they are a) sent to another, secure, machine or b) they are written to a write-once medium (anyone logging onto paper or CD, for example? - grepping a paper ought to be ... fun?). 2) A few people like ssh RSA-auth. Good idea. But I may (will) need access to these machines in situations when there is no network, i.e. running manual fsck's after a power failure. No way of ssh'ing into the box at that time. I will need the root password anyway. 3) A few people would create additional uid=0 accounts. Since my situation is akin to one with multiple admins trusting each other (more exactly - it's _they_ who are trusting _me_, not the other way around), this might be a good idea. No one would have to get familiar with sudo (I know that would cause some resistance - it would be viewed as something they do not need to get accustomed to) and I would get my root. Of course, sudo would give me nice logs of what the others have done - which is quite important if I am to keep the boxes secure: not knowing what's been changed makes that pretty hard. This is my option number 2 anyway, if people resist learning to type 'sudo' instead of logging in as root or saying 'su'. 4) Someone also noted that having linux workstations in the first place is a bad idea due the X's flawed security but I do not seem to remember any way of popping up windows on someone else's display when X server is properly configured (i.e. only to accept connections from localhost with a proper MIT secret cookie (or other auth mechanism). As I said above, in my situation, sudo is very appealing: keeping root password to myself and letting the workstation users sudo (or vice versa). One question raises however: If I have multiple uid=0 accounts, will any of their passwords suffice as "root" password when entering single user mode? Obviously sudo will not do here, so I will need a root password, period. The other users will have to make do with either sudo or multiple uid=0 accounts. Multiple uid=0 accounts sounds better in that it does not elevate ordinary passwords into root passwords (of course, in practice people may keep them the same - can that be helped?) but on the other hand, sudo would log... I will have to see how much use of their root accounts these people really make. Although many of the replies did not answer my question at all, some of them had good points, thanks to those. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
This is completely off-topic at this point, but there are a few uses of sudo. The original poster trusts his admins, and wants to give them all root privs without the hassle of having them all use one account. Sudo is not enforcing anything in this case, it is merely a) allowing convenience by allowing the user to effectively choose their own root passwd. b) allowing a form of audit trail; true, it's easy enough to bypass, but someone trusted wouldn't go out of their way to bypass it. It's good for when (for example) samba suddenly stops working, instead of checking /root/.bash_history for " /etc/smb.conf", running `last` to see when root has logged in since it broke, etc etc, you simply check your logs for the last time someone sudo'd " smb.conf". Make it policy for admins to not use `sudo bash`, or anything similar. What you people are talking about is adding privs to an untrusted account. The (ridiculous) example given, of allowing a user to run /bin/cat, is similar doing a `chown root: /bin/cat; chmod 4770 /bin/cat`. It's dangerous. What a _sane_ admin would do, if the user needed to view a file, is provide the argument to cat that was required. " ALL=(root) /bin/cat /etc/[a-zA-Z]". Or specify the exact filename. If it's an untrusted user, they should be given as little leeway as possible. Allowing them to cat any file on the system is just stupid. On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: > Resent-Date: Fri, 06 Jul 2001 21:11:34 -0400 > > > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: > > Ethan> or even seemingly innocuous things like less or even cat. > > Less is a problem, yes, as is anything else with a shell escape. > > Ethan> sudo less anything !/bin/sh whoami r00t! > > Ethan> echo me ALL=ALL > s sudo 'cat s >> /etc/sudoers' > > doesn't work. the >> is a shell redirection, but sudo doesn't > evaluate in a shell. > > $ echo me ALL=ALL > s > $ cat s > me ALL=ALL > $ sudo 'cat s > foo' > sudo: cat s > foo: command not found > $ sudo cat s \> foo > me ALL=ALL > cat: >: No such file or directory > cat: foo: No such file or directory > > I would be very shocked if you could compromise a system with a > sudoers entry of: > me hostname = (root) /bin/cat > > Ethan> sudo is a very large cannon which is difficult to keep aimed > Ethan> away from the foot... > > That it is. But then, the root password is basically a very large > cannon built into your shoe. > > -Eric > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- "... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed." - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, [EMAIL PROTECTED]
Re: shared root account
- Original Message - From: "Robert L. Yelvington" <[EMAIL PROTECTED]> To: Sent: Friday, July 06, 2001 12:29 PM Subject: Re: shared root account > what's to stop a person, once they've sudo'd, from editing /etc/sudoers and > giving themselves more privs? This is a good reason to run LIDS and make /etc/sudoers truly read-only. -- Ross Thomas <[EMAIL PROTECTED]> + | "The walls are hung with velvet that is black and soft as sin, | And little dwarfs creep out of it and little dwarfs creep in." | | - Lepanto, G. K. Chesterton +
Re: shared root account
This is completely off-topic at this point, but there are a few uses of sudo. The original poster trusts his admins, and wants to give them all root privs without the hassle of having them all use one account. Sudo is not enforcing anything in this case, it is merely a) allowing convenience by allowing the user to effectively choose their own root passwd. b) allowing a form of audit trail; true, it's easy enough to bypass, but someone trusted wouldn't go out of their way to bypass it. It's good for when (for example) samba suddenly stops working, instead of checking /root/.bash_history for " /etc/smb.conf", running `last` to see when root has logged in since it broke, etc etc, you simply check your logs for the last time someone sudo'd " smb.conf". Make it policy for admins to not use `sudo bash`, or anything similar. What you people are talking about is adding privs to an untrusted account. The (ridiculous) example given, of allowing a user to run /bin/cat, is similar doing a `chown root: /bin/cat; chmod 4770 /bin/cat`. It's dangerous. What a _sane_ admin would do, if the user needed to view a file, is provide the argument to cat that was required. " ALL=(root) /bin/cat /etc/[a-zA-Z]". Or specify the exact filename. If it's an untrusted user, they should be given as little leeway as possible. Allowing them to cat any file on the system is just stupid. On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: > Resent-Date: Fri, 06 Jul 2001 21:11:34 -0400 > > > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: > > Ethan> or even seemingly innocuous things like less or even cat. > > Less is a problem, yes, as is anything else with a shell escape. > > Ethan> sudo less anything !/bin/sh whoami r00t! > > Ethan> echo me ALL=ALL > s sudo 'cat s >> /etc/sudoers' > > doesn't work. the >> is a shell redirection, but sudo doesn't > evaluate in a shell. > > $ echo me ALL=ALL > s > $ cat s > me ALL=ALL > $ sudo 'cat s > foo' > sudo: cat s > foo: command not found > $ sudo cat s \> foo > me ALL=ALL > cat: >: No such file or directory > cat: foo: No such file or directory > > I would be very shocked if you could compromise a system with a > sudoers entry of: > me hostname = (root) /bin/cat > > Ethan> sudo is a very large cannon which is difficult to keep aimed > Ethan> away from the foot... > > That it is. But then, the root password is basically a very large > cannon built into your shoe. > > -Eric > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- "... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed." - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
- Original Message - From: "Robert L. Yelvington" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, July 06, 2001 12:29 PM Subject: Re: shared root account > what's to stop a person, once they've sudo'd, from editing /etc/sudoers and > giving themselves more privs? This is a good reason to run LIDS and make /etc/sudoers truly read-only. -- Ross Thomas <[EMAIL PROTECTED]> + | "The walls are hung with velvet that is black and soft as sin, | And little dwarfs creep out of it and little dwarfs creep in." | | - Lepanto, G. K. Chesterton + -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
Eric E Moore <[EMAIL PROTECTED]> writes: > Ok, the amount of aiming away from your foot that you can do with > giving someone priveleges by giving them the root password is a proper > subset of the aiming away from your foot that you can do when > granting priveleges through sudo. Think of a daemon (vtund in this case) that needs to reconfigure interfaces at run time. With sudo, said daemon can run under his own uid and can call ifconfig as root. Definitely better than 'uid 0' all the time.
Re: shared root account
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: Ethan> On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: >> I would be very shocked if you could compromise a system with a >> sudoers entry of: me hostname = (root) /bin/cat Ethan> i would not, being able to read every file on the system, even Ethan> if you can't write is going to lead to compromise sooner or Ethan> later. ok, I *should* have said that it would not give any vulnerabilities other than those granted by being able to read any file on the system. Unexpected compromises, I guess is what I meant, of the nature that putting less in the sudoers file would provide. Ethan> sudo is a very large cannon which is difficult to keep aimed Ethan> away from the foot... >> That it is. But then, the root password is basically a very large >> cannon built into your shoe. Ethan> i would not go that far. Ok, the amount of aiming away from your foot that you can do with giving someone priveleges by giving them the root password is a proper subset of the aiming away from your foot that you can do when granting priveleges through sudo. -Eric
Re: shared root account
Eric E Moore <[EMAIL PROTECTED]> writes: > Ok, the amount of aiming away from your foot that you can do with > giving someone priveleges by giving them the root password is a proper > subset of the aiming away from your foot that you can do when > granting priveleges through sudo. Think of a daemon (vtund in this case) that needs to reconfigure interfaces at run time. With sudo, said daemon can run under his own uid and can call ifconfig as root. Definitely better than 'uid 0' all the time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: Ethan> On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: >> I would be very shocked if you could compromise a system with a >> sudoers entry of: me hostname = (root) /bin/cat Ethan> i would not, being able to read every file on the system, even Ethan> if you can't write is going to lead to compromise sooner or Ethan> later. ok, I *should* have said that it would not give any vulnerabilities other than those granted by being able to read any file on the system. Unexpected compromises, I guess is what I meant, of the nature that putting less in the sudoers file would provide. Ethan> sudo is a very large cannon which is difficult to keep aimed Ethan> away from the foot... >> That it is. But then, the root password is basically a very large >> cannon built into your shoe. Ethan> i would not go that far. Ok, the amount of aiming away from your foot that you can do with giving someone priveleges by giving them the root password is a proper subset of the aiming away from your foot that you can do when granting priveleges through sudo. -Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha J?ykk? wrote: > I have a bit of a situation: I have a handful of linux machines > (almost all with different distributions and kernels and software - > one hell to keep secure) and all the machines have different roots. > These guys want to keep their root passwords (or at least the root > privileges) so they can update their X/KDE/whatever when/if they feel > like it but on the other hand, they would like to see someone (me) > keep their machines secure - something they themselves do not have > time (we all know keeping up security is a fulltime job). Obviously to > install patches etc I, also, need root privileges. Maybe you should try to give them access to change the config files they need to change by giving them group membership in a group like "staff", or something, and making the appropriate config files group writeable and owned by staff. This depends on the competency of the people in question, of course. Some people you can probably trust with their own root accounts. In that case, I'd use ssh identities to let you in as root directly, without having to type their password, only the password protecting your ssh private key. (of course, you'd want to use ssh agent for this.) Also, taking away root access will mean more work for you if they're going to keep asking for permissions to edit more stuff. If you basically trust them, then you should probably let them hold onto root access. I know I personally would like to have root access on my workstation, since the admin doesn't have time to tweak it the way I would like. > This poses a problem if I am not to remember all those different > root passwords and without making all the passwords the same! How can > that _safely_ be accomplished? There are versions of su, sudo etc) that > do not ask passwords, there are suid binaries but which is _THE_ way > of accomplishing this? Presently there are only shared root passwords > between the server admins but now we are trying to get the workstation > security boosted up as well - being behind one firewall does not seem > to be enough in an environment where a whole class B network is behind > that one fw... -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: shared root account
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote: > > alias /bin/su='/var/tmp/hax0rSu' > > i would consider this a bug in the shell. I disagree; from the Bash man page: The alias name and the replacement text may con- tain any valid shell input, including the metacharacters listed above, with the exception that the alias name may not contain =. You could still say maybe it's a policy bug to allow this (and I would continue to disagree); but bug or not, beware - at least bash 2.03 and 2.05, and ash in potato work this way. So do pdksh (/bin/sh) on OpenBSD and /bin/sh (which is the same as our 'ash') on NetBSD. This also works for functions in bash.
Re: shared root account
On Fri, Jul 06, 2001 at 12:15:43PM +0300, Juha J?ykk? wrote: > I have a bit of a situation: I have a handful of linux machines > (almost all with different distributions and kernels and software - > one hell to keep secure) and all the machines have different roots. > These guys want to keep their root passwords (or at least the root > privileges) so they can update their X/KDE/whatever when/if they feel > like it but on the other hand, they would like to see someone (me) > keep their machines secure - something they themselves do not have > time (we all know keeping up security is a fulltime job). Obviously to > install patches etc I, also, need root privileges. Maybe you should try to give them access to change the config files they need to change by giving them group membership in a group like "staff", or something, and making the appropriate config files group writeable and owned by staff. This depends on the competency of the people in question, of course. Some people you can probably trust with their own root accounts. In that case, I'd use ssh identities to let you in as root directly, without having to type their password, only the password protecting your ssh private key. (of course, you'd want to use ssh agent for this.) Also, taking away root access will mean more work for you if they're going to keep asking for permissions to edit more stuff. If you basically trust them, then you should probably let them hold onto root access. I know I personally would like to have root access on my workstation, since the admin doesn't have time to tweak it the way I would like. > This poses a problem if I am not to remember all those different > root passwords and without making all the passwords the same! How can > that _safely_ be accomplished? There are versions of su, sudo etc) that > do not ask passwords, there are suid binaries but which is _THE_ way > of accomplishing this? Presently there are only shared root passwords > between the server admins but now we are trying to get the workstation > security boosted up as well - being behind one firewall does not seem > to be enough in an environment where a whole class B network is behind > that one fw... -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote: > > alias /bin/su='/var/tmp/hax0rSu' > > i would consider this a bug in the shell. I disagree; from the Bash man page: The alias name and the replacement text may con- tain any valid shell input, including the metacharacters listed above, with the exception that the alias name may not contain =. You could still say maybe it's a policy bug to allow this (and I would continue to disagree); but bug or not, beware - at least bash 2.03 and 2.05, and ash in potato work this way. So do pdksh (/bin/sh) on OpenBSD and /bin/sh (which is the same as our 'ash') on NetBSD. This also works for functions in bash. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
[] > yup, which is why nobody gets root but me. if i ever for some reason > decided to go back to sysadmin work a criteria for employment would be > that no manager, sales guy, or other morons would be permitted access > to root for ANY REASON, period, end of story. > > as for sudo for my own purposes i don't see the point, i don't want my > normal account to be a root account nor do i want my user passwd to be > a/the root passwd. the logging is nothing more then an annoyance > since i know what i run anyway. I agree that sudo is not secure enough. But, if you refer the orginal question, seems sudo is the best sol'n. Security or Finish the task. Which would you choose. > -- > Ethan Benson > http://www.alaska.net/~erbenson/
Re: shared root account
[] > yup, which is why nobody gets root but me. if i ever for some reason > decided to go back to sysadmin work a criteria for employment would be > that no manager, sales guy, or other morons would be permitted access > to root for ANY REASON, period, end of story. > > as for sudo for my own purposes i don't see the point, i don't want my > normal account to be a root account nor do i want my user passwd to be > a/the root passwd. the logging is nothing more then an annoyance > since i know what i run anyway. I agree that sudo is not secure enough. But, if you refer the orginal question, seems sudo is the best sol'n. Security or Finish the task. Which would you choose. > -- > Ethan Benson > http://www.alaska.net/~erbenson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Sat, Jul 07, 2001 at 10:31:56AM +, Jim Breton wrote: > On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote: > > which may not work if you always type the > > full path to /bin/su anyway. > > Hoping he doesn't: > > alias /bin/su='/var/tmp/hax0rSu' i would consider this a bug in the shell. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp72aYviKoIB.pgp Description: PGP signature
Re: shared root account
On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote: > which may not work if you always type the > full path to /bin/su anyway. Hoping he doesn't: alias /bin/su='/var/tmp/hax0rSu'
Re: shared root account
On Fri, Jul 06, 2001 at 10:24:28PM -0500, Nathan E Norman wrote: > > Depends on how you use it. > > At my last job, we used sudo for two reasons: > > 1) I didn't have to inform all the admins whenever the root password > changed. which is bogus since changing the root password means changing each and every user's passwd who is listed in /etc/sudoers. > 2) techs had a script which ran as root under sudo for creating user > accounts, etc. The script was written in perl ... I'm sure there was > something wrong with it but it worked well for us and kept techs in > the box where they did the least damage. well thats different, if you write a well audited and secure script for adding users then those allowed to run that won't necessarily be root, still trusted to be sure, but not root. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpxdycyavQpy.pgp Description: PGP signature
Re: shared root account
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: > I would be very shocked if you could compromise a system with a > sudoers entry of: > me hostname = (root) /bin/cat i would not, being able to read every file on the system, even if you can't write is going to lead to compromise sooner or later. > Ethan> sudo is a very large cannon which is difficult to keep aimed > Ethan> away from the foot... > > That it is. But then, the root password is basically a very large > cannon built into your shoe. i would not go that far. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpAs5yVDGC2z.pgp Description: PGP signature
Re: shared root account
On Sat, Jul 07, 2001 at 02:54:27AM +0200, Simon Huggins wrote: > > Any user account that has access to the administrative account if > compromised can give the attacker the admin account etc. > sudo here is no worse than having your account compromised, your keys > sniffed and su really. the difference is it will take longer, with sudo as soon as your user passwd is known root is granted, with su they must try to hack with shell aliases and whatnot. which may not work if you always type the full path to /bin/su anyway. if your attentive you will probably notice the compromise before you su to root yourself, in which case you have saved yourself a root compromise. i have known people who have had root cracked due entirely to sudo. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpI9jkiG2H5X.pgp Description: PGP signature
Re: shared root account
On Fri, Jul 06, 2001 at 05:45:52PM -0700, Vineet Kumar wrote: > You make a good point, even if one of your examples is flawed: > > $ sudo 'cat s >> /etc/sudoers' > sudo: cat s >> /etc/sudoers: command not found er yeah that quoting is bogus, im pretty sure you can do that command in sudo if you properly quote things, then again maybe not, if sudo doesn't use /bin/sh. in any even i can think of dozens and dozens of examples of seemingly innocent programs which can be exploited to give full root. > Okay, so it's not really big or heavy, nor remotely wood. But it does > give you things like this to peer at later: > > Jul 6 17:24:59 gobo sudo: vineet : TTY=pts/1 ; PWD=/tmp/ucspi-tcp ; > USER=root ; COMMAND=/usr/bin/dpkg -i > /home/vineet/ucspi-tcp_0.88-5_i386.deb > Jul 6 17:32:10 gobo sudo: vineet : TTY=pts/2 ; PWD=/etc/init.d ; > USER=root ; COMMAND=/etc/init.d/qmail restart i don't see the benifit to this for two reasons: 1) anytime anyone plans to run more then 2 commands they are just going to run sudo -s or sudo bash and there goes your logging. 2) its quite easy to dispose of those annoying log entries once you have root. both of these combined make sudo's logging all but useless, if anything its a false sense of added security. > Which can be very useful. It's not foolproof by any means, and as you > demonstrate, can usually be trivially reduced to su, but it's better > as a *standard* way of doing things on a system on which multiple people > play root. If you can't trust those people, then you're screwed no > matter what tools you use. yup, which is why nobody gets root but me. if i ever for some reason decided to go back to sysadmin work a criteria for employment would be that no manager, sales guy, or other morons would be permitted access to root for ANY REASON, period, end of story. as for sudo for my own purposes i don't see the point, i don't want my normal account to be a root account nor do i want my user passwd to be a/the root passwd. the logging is nothing more then an annoyance since i know what i run anyway. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp0WvTJ3eR08.pgp Description: PGP signature
Re: shared root account
On Sat, Jul 07, 2001 at 10:31:56AM +, Jim Breton wrote: > On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote: > > which may not work if you always type the > > full path to /bin/su anyway. > > Hoping he doesn't: > > alias /bin/su='/var/tmp/hax0rSu' i would consider this a bug in the shell. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: shared root account
On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote: > which may not work if you always type the > full path to /bin/su anyway. Hoping he doesn't: alias /bin/su='/var/tmp/hax0rSu' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Fri, Jul 06, 2001 at 10:24:28PM -0500, Nathan E Norman wrote: > > Depends on how you use it. > > At my last job, we used sudo for two reasons: > > 1) I didn't have to inform all the admins whenever the root password > changed. which is bogus since changing the root password means changing each and every user's passwd who is listed in /etc/sudoers. > 2) techs had a script which ran as root under sudo for creating user > accounts, etc. The script was written in perl ... I'm sure there was > something wrong with it but it worked well for us and kept techs in > the box where they did the least damage. well thats different, if you write a well audited and secure script for adding users then those allowed to run that won't necessarily be root, still trusted to be sure, but not root. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: shared root account
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: > I would be very shocked if you could compromise a system with a > sudoers entry of: > me hostname = (root) /bin/cat i would not, being able to read every file on the system, even if you can't write is going to lead to compromise sooner or later. > Ethan> sudo is a very large cannon which is difficult to keep aimed > Ethan> away from the foot... > > That it is. But then, the root password is basically a very large > cannon built into your shoe. i would not go that far. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: shared root account
On Sat, Jul 07, 2001 at 02:54:27AM +0200, Simon Huggins wrote: > > Any user account that has access to the administrative account if > compromised can give the attacker the admin account etc. > sudo here is no worse than having your account compromised, your keys > sniffed and su really. the difference is it will take longer, with sudo as soon as your user passwd is known root is granted, with su they must try to hack with shell aliases and whatnot. which may not work if you always type the full path to /bin/su anyway. if your attentive you will probably notice the compromise before you su to root yourself, in which case you have saved yourself a root compromise. i have known people who have had root cracked due entirely to sudo. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: shared root account
On Fri, Jul 06, 2001 at 05:45:52PM -0700, Vineet Kumar wrote: > You make a good point, even if one of your examples is flawed: > > $ sudo 'cat s >> /etc/sudoers' > sudo: cat s >> /etc/sudoers: command not found er yeah that quoting is bogus, im pretty sure you can do that command in sudo if you properly quote things, then again maybe not, if sudo doesn't use /bin/sh. in any even i can think of dozens and dozens of examples of seemingly innocent programs which can be exploited to give full root. > Okay, so it's not really big or heavy, nor remotely wood. But it does > give you things like this to peer at later: > > Jul 6 17:24:59 gobo sudo: vineet : TTY=pts/1 ; PWD=/tmp/ucspi-tcp ; > USER=root ; COMMAND=/usr/bin/dpkg -i > /home/vineet/ucspi-tcp_0.88-5_i386.deb > Jul 6 17:32:10 gobo sudo: vineet : TTY=pts/2 ; PWD=/etc/init.d ; > USER=root ; COMMAND=/etc/init.d/qmail restart i don't see the benifit to this for two reasons: 1) anytime anyone plans to run more then 2 commands they are just going to run sudo -s or sudo bash and there goes your logging. 2) its quite easy to dispose of those annoying log entries once you have root. both of these combined make sudo's logging all but useless, if anything its a false sense of added security. > Which can be very useful. It's not foolproof by any means, and as you > demonstrate, can usually be trivially reduced to su, but it's better > as a *standard* way of doing things on a system on which multiple people > play root. If you can't trust those people, then you're screwed no > matter what tools you use. yup, which is why nobody gets root but me. if i ever for some reason decided to go back to sysadmin work a criteria for employment would be that no manager, sales guy, or other morons would be permitted access to root for ANY REASON, period, end of story. as for sudo for my own purposes i don't see the point, i don't want my normal account to be a root account nor do i want my user passwd to be a/the root passwd. the logging is nothing more then an annoyance since i know what i run anyway. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: shared root account
On Sat, Jul 07, 2001 at 12:11:44AM -0600, Will Aoki wrote: > On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: > [cut] > > I would be very shocked if you could compromise a system with a > > sudoers entry of: > > me hostname = (root) /bin/cat > > Depends on what's on the system. I've thought of four similar ways. Hmm, you forgot the obvious: sudo cat /etc/shadow > foo -- Steven Barker [EMAIL PROTECTED] It'll be just like Beggars' Canyon back home. -- Luke Skywalker PGP Key Fingerprint: 1A33 9F2E 368D 24B1 81D4 60BF E928 9E28 958F 2058
Re: shared root account
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: [cut] > I would be very shocked if you could compromise a system with a > sudoers entry of: > me hostname = (root) /bin/cat Depends on what's on the system. I've thought of four similar ways. 1: With Kerberos, you can steal someone's ticket-granting ticket and use it until it expires. My example also uses AFS: | [EMAIL PROTECTED]:~$ klist | Ticket cache: FILE:/tmp/krb5cc_q5bOCp | Default principal: [EMAIL PROTECTED] | | Valid starting ExpiresService principal | 07/06/01 22:29:11 07/07/01 08:29:11 host/[EMAIL PROTECTED] | 07/06/01 22:29:11 07/07/01 08:29:11 krbtgt/[EMAIL PROTECTED] | 07/06/01 22:29:11 07/07/01 08:29:11 afs/[EMAIL PROTECTED] | | | Kerberos 4 ticket cache: /tmp/tkt1001 | klist: You have no tickets cached | [EMAIL PROTECTED]:~$ cd /tmp | [EMAIL PROTECTED]:/tmp$ ls -al | total 20 | drwxrwxrwt3 root root 1024 Jul 6 22:29 . | drwxr-xr-x 21 root root 1024 Jun 27 23:41 .. | -rw---1 waokiwaoki 892 Jul 6 01:40 krb5cc_1002 | -rw---1 waokiwaoki 848 Jul 6 22:22 krb5cc_GMJQN9 | -rw---1 test test 885 Jul 6 22:28 krb5cc_SyJR0W | -rw---1 test test 885 Jul 6 22:26 krb5cc_YzLI0R | -rw---1 test test 1243 Jul 6 22:29 krb5cc_q5bOCp | drwxr-xr-x2 root root12288 Nov 14 2000 lost+found | [EMAIL PROTECTED]:/tmp$ ls -al /afs/g6net.com/user/waoki/secure | ls: /afs/g6net.com/user/waoki/secure: Permission denied | [EMAIL PROTECTED]:/afs/g6net.com/user/waoki$ touch /afs/g6net.com/user/waoki/afile | touch: creating `/afs/g6net.com/user/waoki/afile': Permission denied Nope, can't access someone else's homedir... | [EMAIL PROTECTED]:/tmp$ sudo -v | | We trust you have received the usual lecture from the local System | Administrator. It usually boils down to these two things: | | #1) Respect the privacy of others. | #2) Think before you type. | | Password for [EMAIL PROTECTED]: Now we steal a TGT (but we could also go after the keytab)... | [EMAIL PROTECTED]:/tmp$ sudo /bin/cat krb5cc_GMJQN9 > krb5cc_q5bOCp | [EMAIL PROTECTED]:/tmp$ aklog ...and now I'm someone else! | [EMAIL PROTECTED]:/tmp$ klist | Ticket cache: FILE:/tmp/krb5cc_q5bOCp | Default principal: [EMAIL PROTECTED] | | Valid starting ExpiresService principal | 07/06/01 22:21:56 07/07/01 08:21:52 krbtgt/[EMAIL PROTECTED] | 07/06/01 22:22:03 07/07/01 08:21:52 afs/[EMAIL PROTECTED] | | | Kerberos 4 ticket cache: /tmp/tkt1001 | klist: You have no tickets cached | | [EMAIL PROTECTED]:/tmp$ ls -al /afs/g6net.com/user/waoki/secure | total 4 | drwxr-xr-x2 waokiwaoki2048 Jul 6 01:39 . | drwxr-xr-x5 waokiwaoki2048 Jul 6 22:33 .. | -rw-r--r--1 waokiwaoki 0 Jul 6 01:39 file (As an aside, although the 'secure' directory above is mode 755, it's on AFS, so the Unix mode bits don't apply.) Now let's set up some trojans: | [EMAIL PROTECTED]:/tmp$ cp ~/.su.trojan ~/.sudo.trojan ~/.kadmin.trojan /afs/g6net.com/user/waoki/ | [EMAIL PROTECTED]:/tmp$ echo alias su=~/.su.trojan >> /afs/g6net.com/user/waoki/.bashrc | [EMAIL PROTECTED]:/tmp$ echo alias /bin/su=~/.su.trojan >> /afs/g6net.com/user/waoki/.bashrc | [EMAIL PROTECTED]:/tmp$ echo alias sudo=~/.sudo.trojan >> /afs/g6net.com/user/waoki/.bashrc | [EMAIL PROTECTED]:/tmp$ echo alias /usr/bin/sudo=~/.sudo.trojan >> /afs/g6net.com/user/waoki/.bashrc | [EMAIL PROTECTED]:/tmp$ echo alias kadmin=~/.kadmin.trojan >> /afs/g6net.com/user/waoki/.bashrc | [EMAIL PROTECTED]:/tmp$ echo alias /usr/sbin/kadmin=~/.kadmin.trojan >> /afs/g6net.com/user/waoki/.bashrc | [EMAIL PROTECTED]:/tmp$ 2: Something similar could be done if someone's ssh identity or id_dsa keys aren't password protected: | [EMAIL PROTECTED] test]$ sudo cat /home/waoki/.ssh/id_dsa > .ssh/id_dsa | [EMAIL PROTECTED] test]$ ssh localhost -l waoki and now I can trojan apps, or (since the default Debian sudo uses one timestamp file per user, instead of one per user per tty) I can wait for the victim to sudo, and then sudo without entering his password. 3 and 4: If the system's running Samba, access to /etc/smbpasswd lets me log in to Samba as anyone who appears in /etc/smbpasswd. If the system is using Netatalk with randnum authentication, users' AppleTalk passwords will be stored in plaintext in ~/.passwd. Once again, I can trojan binaries and scripts. Oh, and catting /proc/kcore could yield interesting information. -- William Aoki[EMAIL PROTECTED] (801)-(58)5-1924 UMNH Computer Support Room 001, GTB (801)-(58)1-6928 1390 E President's Circle Salt Lake City, Utah84112-0050 Key 199D8C7B Fingerprint 3B0A 6800 8A1A 78A7 9A26 BB92 6329 2D3E 199D 8C7B
Re: shared root account
On Fri, 06 Jul 2001, Juha J?ykk? <[EMAIL PROTECTED]> wrote... : > > (Put the public key in the .authorized_keys file for the root user) : > > TUrn on RSA/DSA authentication and 'allow root login' : > One word of warning aboce would allow logging in using root password as well : : I distrust allowing root logins from anywhere but local console(s) : or non-modem gettys i.e. from anywhere over the not-owned-by-me cable. : Any other ideas? Or is it really safe to allow root logins to sshd? : It is just an old rule of thumb that root must never log on over the : wire but that may be old news from times of telnet - never had any : need of root logins over the wire until perhaps now. Try using ssh keys, as described above, however, in the ~root/.ssh/authorised_keys file, prepend all the keys with from="127.0.0.1" /dopey
Re: shared root account
On Sat, Jul 07, 2001 at 12:11:44AM -0600, Will Aoki wrote: > On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: > [cut] > > I would be very shocked if you could compromise a system with a > > sudoers entry of: > > me hostname = (root) /bin/cat > > Depends on what's on the system. I've thought of four similar ways. Hmm, you forgot the obvious: sudo cat /etc/shadow > foo -- Steven Barker [EMAIL PROTECTED] It'll be just like Beggars' Canyon back home. -- Luke Skywalker PGP Key Fingerprint: 1A33 9F2E 368D 24B1 81D4 60BF E928 9E28 958F 2058 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: [cut] > I would be very shocked if you could compromise a system with a > sudoers entry of: > me hostname = (root) /bin/cat Depends on what's on the system. I've thought of four similar ways. 1: With Kerberos, you can steal someone's ticket-granting ticket and use it until it expires. My example also uses AFS: | test@pentagram:~$ klist | Ticket cache: FILE:/tmp/krb5cc_q5bOCp | Default principal: [EMAIL PROTECTED] | | Valid starting ExpiresService principal | 07/06/01 22:29:11 07/07/01 08:29:11 [EMAIL PROTECTED] | 07/06/01 22:29:11 07/07/01 08:29:11 [EMAIL PROTECTED] | 07/06/01 22:29:11 07/07/01 08:29:11 [EMAIL PROTECTED] | | | Kerberos 4 ticket cache: /tmp/tkt1001 | klist: You have no tickets cached | test@pentagram:~$ cd /tmp | test@pentagram:/tmp$ ls -al | total 20 | drwxrwxrwt3 root root 1024 Jul 6 22:29 . | drwxr-xr-x 21 root root 1024 Jun 27 23:41 .. | -rw---1 waokiwaoki 892 Jul 6 01:40 krb5cc_1002 | -rw---1 waokiwaoki 848 Jul 6 22:22 krb5cc_GMJQN9 | -rw---1 test test 885 Jul 6 22:28 krb5cc_SyJR0W | -rw---1 test test 885 Jul 6 22:26 krb5cc_YzLI0R | -rw---1 test test 1243 Jul 6 22:29 krb5cc_q5bOCp | drwxr-xr-x2 root root12288 Nov 14 2000 lost+found | test@pentagram:/tmp$ ls -al /afs/g6net.com/user/waoki/secure | ls: /afs/g6net.com/user/waoki/secure: Permission denied | test@pentagram:/afs/g6net.com/user/waoki$ touch /afs/g6net.com/user/waoki/afile | touch: creating `/afs/g6net.com/user/waoki/afile': Permission denied Nope, can't access someone else's homedir... | test@pentagram:/tmp$ sudo -v | | We trust you have received the usual lecture from the local System | Administrator. It usually boils down to these two things: | | #1) Respect the privacy of others. | #2) Think before you type. | | Password for [EMAIL PROTECTED]: Now we steal a TGT (but we could also go after the keytab)... | test@pentagram:/tmp$ sudo /bin/cat krb5cc_GMJQN9 > krb5cc_q5bOCp | test@pentagram:/tmp$ aklog ...and now I'm someone else! | test@pentagram:/tmp$ klist | Ticket cache: FILE:/tmp/krb5cc_q5bOCp | Default principal: [EMAIL PROTECTED] | | Valid starting ExpiresService principal | 07/06/01 22:21:56 07/07/01 08:21:52 [EMAIL PROTECTED] | 07/06/01 22:22:03 07/07/01 08:21:52 [EMAIL PROTECTED] | | | Kerberos 4 ticket cache: /tmp/tkt1001 | klist: You have no tickets cached | | test@pentagram:/tmp$ ls -al /afs/g6net.com/user/waoki/secure | total 4 | drwxr-xr-x2 waokiwaoki2048 Jul 6 01:39 . | drwxr-xr-x5 waokiwaoki2048 Jul 6 22:33 .. | -rw-r--r--1 waokiwaoki 0 Jul 6 01:39 file (As an aside, although the 'secure' directory above is mode 755, it's on AFS, so the Unix mode bits don't apply.) Now let's set up some trojans: | test@pentagram:/tmp$ cp ~/.su.trojan ~/.sudo.trojan ~/.kadmin.trojan |/afs/g6net.com/user/waoki/ | test@pentagram:/tmp$ echo alias su=~/.su.trojan >> /afs/g6net.com/user/waoki/.bashrc | test@pentagram:/tmp$ echo alias /bin/su=~/.su.trojan >> |/afs/g6net.com/user/waoki/.bashrc | test@pentagram:/tmp$ echo alias sudo=~/.sudo.trojan >> |/afs/g6net.com/user/waoki/.bashrc | test@pentagram:/tmp$ echo alias /usr/bin/sudo=~/.sudo.trojan >> |/afs/g6net.com/user/waoki/.bashrc | test@pentagram:/tmp$ echo alias kadmin=~/.kadmin.trojan >> |/afs/g6net.com/user/waoki/.bashrc | test@pentagram:/tmp$ echo alias /usr/sbin/kadmin=~/.kadmin.trojan >> |/afs/g6net.com/user/waoki/.bashrc | test@pentagram:/tmp$ 2: Something similar could be done if someone's ssh identity or id_dsa keys aren't password protected: | [test@tertia test]$ sudo cat /home/waoki/.ssh/id_dsa > .ssh/id_dsa | [test@tertia test]$ ssh localhost -l waoki and now I can trojan apps, or (since the default Debian sudo uses one timestamp file per user, instead of one per user per tty) I can wait for the victim to sudo, and then sudo without entering his password. 3 and 4: If the system's running Samba, access to /etc/smbpasswd lets me log in to Samba as anyone who appears in /etc/smbpasswd. If the system is using Netatalk with randnum authentication, users' AppleTalk passwords will be stored in plaintext in ~/.passwd. Once again, I can trojan binaries and scripts. Oh, and catting /proc/kcore could yield interesting information. -- William Aoki[EMAIL PROTECTED] (801)-(58)5-1924 UMNH Computer Support Room 001, GTB (801)-(58)1-6928 1390 E President's Circle Salt Lake City, Utah84112-0050 Key 199D8C7B Fingerprint 3B0A 6800 8A1A 78A7 9A26 BB92 6329 2D3E 199D 8C7B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Fri, 06 Jul 2001, Juha J?ykk? <[EMAIL PROTECTED]> wrote... : > > (Put the public key in the .authorized_keys file for the root user) : > > TUrn on RSA/DSA authentication and 'allow root login' : > One word of warning aboce would allow logging in using root password as well : : I distrust allowing root logins from anywhere but local console(s) : or non-modem gettys i.e. from anywhere over the not-owned-by-me cable. : Any other ideas? Or is it really safe to allow root logins to sshd? : It is just an old rule of thumb that root must never log on over the : wire but that may be old news from times of telnet - never had any : need of root logins over the wire until perhaps now. Try using ssh keys, as described above, however, in the ~root/.ssh/authorised_keys file, prepend all the keys with from="127.0.0.1" /dopey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Fri, Jul 06, 2001 at 03:24:56PM -0800, Ethan Benson wrote: > On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote: > > > > OTOH if you restrict the user to a list of commands in /etc/sudoers, > > it's wise to consider whether the user might be able to leverage one of > > those commands to edit /etc/sudoers (or any other file). If you're > > going to list "emacs" or "vi" in /etc/sudoers, you might as well just > > list "ALL" :) > > or even seemingly innocuous things like less or even cat. > > sudo less anything > !/bin/sh > whoami > r00t! > > echo me ALL=ALL > s > sudo 'cat s >> /etc/sudoers' IOW, it's safe to say that allowing access to a shell via sudo means you trust that user as root. > sudo is a very large cannon which is difficult to keep aimed away from > the foot... Depends on how you use it. At my last job, we used sudo for two reasons: 1) I didn't have to inform all the admins whenever the root password changed. 2) techs had a script which ran as root under sudo for creating user accounts, etc. The script was written in perl ... I'm sure there was something wrong with it but it worked well for us and kept techs in the box where they did the least damage. Cheers, -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpJ8WZEmTXDr.pgp Description: PGP signature
Re: shared root account
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: Ethan> or even seemingly innocuous things like less or even cat. Less is a problem, yes, as is anything else with a shell escape. Ethan> sudo less anything !/bin/sh whoami r00t! Ethan> echo me ALL=ALL > s sudo 'cat s >> /etc/sudoers' doesn't work. the >> is a shell redirection, but sudo doesn't evaluate in a shell. $ echo me ALL=ALL > s $ cat s me ALL=ALL $ sudo 'cat s > foo' sudo: cat s > foo: command not found $ sudo cat s \> foo me ALL=ALL cat: >: No such file or directory cat: foo: No such file or directory I would be very shocked if you could compromise a system with a sudoers entry of: me hostname = (root) /bin/cat Ethan> sudo is a very large cannon which is difficult to keep aimed Ethan> away from the foot... That it is. But then, the root password is basically a very large cannon built into your shoe. -Eric
Re: shared root account
On Fri, Jul 06, 2001 at 03:24:56PM -0800, Ethan Benson wrote: > On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote: > > > > OTOH if you restrict the user to a list of commands in /etc/sudoers, > > it's wise to consider whether the user might be able to leverage one of > > those commands to edit /etc/sudoers (or any other file). If you're > > going to list "emacs" or "vi" in /etc/sudoers, you might as well just > > list "ALL" :) > > or even seemingly innocuous things like less or even cat. > > sudo less anything > !/bin/sh > whoami > r00t! > > echo me ALL=ALL > s > sudo 'cat s >> /etc/sudoers' IOW, it's safe to say that allowing access to a shell via sudo means you trust that user as root. > sudo is a very large cannon which is difficult to keep aimed away from > the foot... Depends on how you use it. At my last job, we used sudo for two reasons: 1) I didn't have to inform all the admins whenever the root password changed. 2) techs had a script which ran as root under sudo for creating user accounts, etc. The script was written in perl ... I'm sure there was something wrong with it but it worked well for us and kept techs in the box where they did the least damage. Cheers, -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton PGP signature
Re: shared root account
On Fri, Jul 06, 2001 at 06:15:43AM -0800, Ethan Benson wrote: > the main reason i don't use sudo except for small things which cannot > grant a root shell in any way is for the simple reason the sudo > converts a normal unprivleged user password into another root > password. Any user account that has access to the administrative account if compromised can give the attacker the admin account etc. sudo here is no worse than having your account compromised, your keys sniffed and su really. Simon. -- oOoOo "CATS. CATS ARE NICE." - Death, "Sourcery" oOoOo oOoOooOoOo oOoOo oOoOo htag.pl 0.0.19 ::: http://www.earth.li/~huggie/
Re: shared root account
You make a good point, even if one of your examples is flawed:
$ sudo 'cat s >> /etc/sudoers'
sudo: cat s >> /etc/sudoers: command not found
sudo is a very useful tool in the type of situation described in this
thread. Even if you give everyone ALL=(ALL) ALL, it's better than su
or even .ssh/authorized_keys{,2} because of one thing in particular:
It's log! It's loog! It's big! It's heavy! It's wood!
Okay, so it's not really big or heavy, nor remotely wood. But it does
give you things like this to peer at later:
Jul 6 17:24:59 gobo sudo: vineet : TTY=pts/1 ; PWD=/tmp/ucspi-tcp ;
USER=root ; COMMAND=/usr/bin/dpkg -i
/home/vineet/ucspi-tcp_0.88-5_i386.deb
Jul 6 17:32:10 gobo sudo: vineet : TTY=pts/2 ; PWD=/etc/init.d ;
USER=root ; COMMAND=/etc/init.d/qmail restart
Which can be very useful. It's not foolproof by any means, and as you
demonstrate, can usually be trivially reduced to su, but it's better
as a *standard* way of doing things on a system on which multiple people
play root. If you can't trust those people, then you're screwed no
matter what tools you use.
Vineet
* Ethan Benson ([EMAIL PROTECTED]) [010706 16:27]:
> On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote:
> >
> > OTOH if you restrict the user to a list of commands in /etc/sudoers,
> > it's wise to consider whether the user might be able to leverage one of
> > those commands to edit /etc/sudoers (or any other file). If you're
> > going to list "emacs" or "vi" in /etc/sudoers, you might as well just
> > list "ALL" :)
>
> or even seemingly innocuous things like less or even cat.
>
> sudo less anything
> !/bin/sh
> whoami
> r00t!
>
> echo me ALL=ALL > s
> sudo 'cat s >> /etc/sudoers'
>
> sudo is a very large cannon which is difficult to keep aimed away from
> the foot...
>
> --
> Ethan Benson
> http://www.alaska.net/~erbenson/
pgplw7jW3RBN4.pgp
Description: PGP signature
Re: shared root account
On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote: > > OTOH if you restrict the user to a list of commands in /etc/sudoers, > it's wise to consider whether the user might be able to leverage one of > those commands to edit /etc/sudoers (or any other file). If you're > going to list "emacs" or "vi" in /etc/sudoers, you might as well just > list "ALL" :) or even seemingly innocuous things like less or even cat. sudo less anything !/bin/sh whoami r00t! echo me ALL=ALL > s sudo 'cat s >> /etc/sudoers' sudo is a very large cannon which is difficult to keep aimed away from the foot... -- Ethan Benson http://www.alaska.net/~erbenson/ pgpZgdNZaFtrL.pgp Description: PGP signature
Re: shared root account
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes: Ethan> or even seemingly innocuous things like less or even cat. Less is a problem, yes, as is anything else with a shell escape. Ethan> sudo less anything !/bin/sh whoami r00t! Ethan> echo me ALL=ALL > s sudo 'cat s >> /etc/sudoers' doesn't work. the >> is a shell redirection, but sudo doesn't evaluate in a shell. $ echo me ALL=ALL > s $ cat s me ALL=ALL $ sudo 'cat s > foo' sudo: cat s > foo: command not found $ sudo cat s \> foo me ALL=ALL cat: >: No such file or directory cat: foo: No such file or directory I would be very shocked if you could compromise a system with a sudoers entry of: me hostname = (root) /bin/cat Ethan> sudo is a very large cannon which is difficult to keep aimed Ethan> away from the foot... That it is. But then, the root password is basically a very large cannon built into your shoe. -Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Fri, Jul 06, 2001 at 06:15:43AM -0800, Ethan Benson wrote: > the main reason i don't use sudo except for small things which cannot > grant a root shell in any way is for the simple reason the sudo > converts a normal unprivleged user password into another root > password. Any user account that has access to the administrative account if compromised can give the attacker the admin account etc. sudo here is no worse than having your account compromised, your keys sniffed and su really. Simon. -- oOoOo "CATS. CATS ARE NICE." - Death, "Sourcery" oOoOo oOoOooOoOo oOoOo oOoOo htag.pl 0.0.19 ::: http://www.earth.li/~huggie/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
You make a good point, even if one of your examples is flawed:
$ sudo 'cat s >> /etc/sudoers'
sudo: cat s >> /etc/sudoers: command not found
sudo is a very useful tool in the type of situation described in this
thread. Even if you give everyone ALL=(ALL) ALL, it's better than su
or even .ssh/authorized_keys{,2} because of one thing in particular:
It's log! It's loog! It's big! It's heavy! It's wood!
Okay, so it's not really big or heavy, nor remotely wood. But it does
give you things like this to peer at later:
Jul 6 17:24:59 gobo sudo: vineet : TTY=pts/1 ; PWD=/tmp/ucspi-tcp ;
USER=root ; COMMAND=/usr/bin/dpkg -i
/home/vineet/ucspi-tcp_0.88-5_i386.deb
Jul 6 17:32:10 gobo sudo: vineet : TTY=pts/2 ; PWD=/etc/init.d ;
USER=root ; COMMAND=/etc/init.d/qmail restart
Which can be very useful. It's not foolproof by any means, and as you
demonstrate, can usually be trivially reduced to su, but it's better
as a *standard* way of doing things on a system on which multiple people
play root. If you can't trust those people, then you're screwed no
matter what tools you use.
Vineet
* Ethan Benson ([EMAIL PROTECTED]) [010706 16:27]:
> On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote:
> >
> > OTOH if you restrict the user to a list of commands in /etc/sudoers,
> > it's wise to consider whether the user might be able to leverage one of
> > those commands to edit /etc/sudoers (or any other file). If you're
> > going to list "emacs" or "vi" in /etc/sudoers, you might as well just
> > list "ALL" :)
>
> or even seemingly innocuous things like less or even cat.
>
> sudo less anything
> !/bin/sh
> whoami
> r00t!
>
> echo me ALL=ALL > s
> sudo 'cat s >> /etc/sudoers'
>
> sudo is a very large cannon which is difficult to keep aimed away from
> the foot...
>
> --
> Ethan Benson
> http://www.alaska.net/~erbenson/
PGP signature
Re: shared root account
On Fri, Jul 06, 2001 at 09:43:55AM -0500, Nathan E Norman wrote: > > OTOH if you restrict the user to a list of commands in /etc/sudoers, > it's wise to consider whether the user might be able to leverage one of > those commands to edit /etc/sudoers (or any other file). If you're > going to list "emacs" or "vi" in /etc/sudoers, you might as well just > list "ALL" :) or even seemingly innocuous things like less or even cat. sudo less anything !/bin/sh whoami r00t! echo me ALL=ALL > s sudo 'cat s >> /etc/sudoers' sudo is a very large cannon which is difficult to keep aimed away from the foot... -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: shared root account
At 994418143s since epoch (07/06/01 10:15:43 -0400 UTC), Ethan Benson wrote: > On Fri, Jul 06, 2001 at 09:18:18AM -0400, Jason Healy wrote: > > types of > > passwords accepted to run root commands, etc). > > elaborate. > > the main reason i don't use sudo except for small things which cannot > grant a root shell in any way is for the simple reason the sudo > converts a normal unprivleged user password into another root > password. I'm not a sudo expert, but I do use it and like it. I'll try to answer the questions asked here, but you really should READ THE DOCS before you believe everything I say. To your point (types of passwords), you can configure sudo (I think using PAM) to only work with user passwords, or one-time passwords (OTP), or whatever else PAM will take. This allows you to force sudo users to use passwords other than their standard account passwords. I'm a fan of OTP because when used correctly they're very secure, even over insecure connections (telnet). Other people asked why sudo is better than su. The main reason is audit trail; sudo keeps logs of commands. Additionally, you can grant limited command access to people. Admittedly, most commands can be leveraged to gain full root privs (shells, editors, cat, chmod, and so on), so you need to TRUST people you're giving sudo to. However, sudo is never any more dangerous than plain old su, if you think about it. Also, you don't want root logins to be a normal thing. You want to KNOW if root is logged in on your box. Script kiddies trying to get in will try to get in as root first. If you often log in as root, it's less likely that you'll notice if someone else logs in as root. Also, if you never use root as your login, you can restrict it severely (only allow root logins on the console, for example). Kiddies who break into user accounts pose less of a threat. Sure, one of those user accounts might be sudo-enabled, but to find out for sure, they have to run a command under sudo. If they aren't in the sudoers file, then sudo will log the incident and e-mail it to root. The odds of a script kiddie randomly hacking a sudo-enabled account on a box with hundreds of accounts is very low. Especially because anybody you give sudo to should be extra careful about security. Whew... that was a rant. Anyway, here are my tips for using sudo well. Feel free to add your own: 1) Trust the people you give sudo to (assume they can get root with whatever access you give them) 2) Make sure those people are extra anal about security (secure logins, good passwords, etc) 3) Check your logs religiously 4) Disable root from logging in, except from the console 5) Never log in as root. Use 'sudo -s' to get a shell if you must 6) Clamp down sudo as much as you are comfortable with, but don't drive people nuts. For example, think about using OTP, but don't do it if people are going to hate it so much that they'll undermine the system. Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/
Re: shared root account
Juha Jäykkä <[EMAIL PROTECTED]> writes: > Any other ideas? Or is it really safe to allow root logins to sshd? > It is just an old rule of thumb that root must never log on over the > wire but that may be old news from times of telnet - never had any > need of root logins over the wire until perhaps now. The traditional reason for disallowing root logins has nothing to do with security; the reason is to give (maybe) more accountability because a real user id is logged along with the actions that root does.
Re: shared root account
At 994418143s since epoch (07/06/01 10:15:43 -0400 UTC), Ethan Benson wrote: > On Fri, Jul 06, 2001 at 09:18:18AM -0400, Jason Healy wrote: > > types of > > passwords accepted to run root commands, etc). > > elaborate. > > the main reason i don't use sudo except for small things which cannot > grant a root shell in any way is for the simple reason the sudo > converts a normal unprivleged user password into another root > password. I'm not a sudo expert, but I do use it and like it. I'll try to answer the questions asked here, but you really should READ THE DOCS before you believe everything I say. To your point (types of passwords), you can configure sudo (I think using PAM) to only work with user passwords, or one-time passwords (OTP), or whatever else PAM will take. This allows you to force sudo users to use passwords other than their standard account passwords. I'm a fan of OTP because when used correctly they're very secure, even over insecure connections (telnet). Other people asked why sudo is better than su. The main reason is audit trail; sudo keeps logs of commands. Additionally, you can grant limited command access to people. Admittedly, most commands can be leveraged to gain full root privs (shells, editors, cat, chmod, and so on), so you need to TRUST people you're giving sudo to. However, sudo is never any more dangerous than plain old su, if you think about it. Also, you don't want root logins to be a normal thing. You want to KNOW if root is logged in on your box. Script kiddies trying to get in will try to get in as root first. If you often log in as root, it's less likely that you'll notice if someone else logs in as root. Also, if you never use root as your login, you can restrict it severely (only allow root logins on the console, for example). Kiddies who break into user accounts pose less of a threat. Sure, one of those user accounts might be sudo-enabled, but to find out for sure, they have to run a command under sudo. If they aren't in the sudoers file, then sudo will log the incident and e-mail it to root. The odds of a script kiddie randomly hacking a sudo-enabled account on a box with hundreds of accounts is very low. Especially because anybody you give sudo to should be extra careful about security. Whew... that was a rant. Anyway, here are my tips for using sudo well. Feel free to add your own: 1) Trust the people you give sudo to (assume they can get root with whatever access you give them) 2) Make sure those people are extra anal about security (secure logins, good passwords, etc) 3) Check your logs religiously 4) Disable root from logging in, except from the console 5) Never log in as root. Use 'sudo -s' to get a shell if you must 6) Clamp down sudo as much as you are comfortable with, but don't drive people nuts. For example, think about using OTP, but don't do it if people are going to hate it so much that they'll undermine the system. Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
Juha Jäykkä <[EMAIL PROTECTED]> writes: > Any other ideas? Or is it really safe to allow root logins to sshd? > It is just an old rule of thumb that root must never log on over the > wire but that may be old news from times of telnet - never had any > need of root logins over the wire until perhaps now. The traditional reason for disallowing root logins has nothing to do with security; the reason is to give (maybe) more accountability because a real user id is logged along with the actions that root does. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Fri, Jul 06, 2001 at 09:29:54AM -0700, Robert L. Yelvington wrote: > admittedly, i am not very familiar with sudo because i have never seen the > practical advantages of making su'ing more of a hassle by having to manage > another set of conf files and keeping track of who's a sudoer and, > therefore, have chosen not to use it. > > what's to stop a person, once they've sudo'd, from editing /etc/sudoers and > giving themselves more privs? [ please avoid jeopardy style quoting ] If sudo already allows a user to run "ALL" commands as root, what privs could they possibly gain? OTOH if you restrict the user to a list of commands in /etc/sudoers, it's wise to consider whether the user might be able to leverage one of those commands to edit /etc/sudoers (or any other file). If you're going to list "emacs" or "vi" in /etc/sudoers, you might as well just list "ALL" :) -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpI4pZGDfr8C.pgp Description: PGP signature
Re: shared root account
"Robert L. Yelvington" <[EMAIL PROTECTED]> writes: > what's to stop a person, once they've sudo'd, from editing /etc/sudoers and > giving themselves more privs? sudo is to stop them, perhaps? ~Tim -- 15:40:15 up 9 days, 23:50, 12 users, load average: 0.19, 0.04, 0.01 [EMAIL PROTECTED] |The light of the world keeps shining, http://piglet.is.dreaming.org |Bright in the primal glow
Re: shared root account
admittedly, i am not very familiar with sudo because i have never seen the practical advantages of making su'ing more of a hassle by having to manage another set of conf files and keeping track of who's a sudoer and, therefore, have chosen not to use it. what's to stop a person, once they've sudo'd, from editing /etc/sudoers and giving themselves more privs? kind regards, ~rob on 7/6/01 6:57 AM, Steve Greenland at [EMAIL PROTECTED] wrote: > On 06-Jul-01, 05:34 (CDT), Patrice Neff <[EMAIL PROTECTED]> wrote: >> What you want to accomplish might be possible with sudo. Install sudo >> and thenn add the following line to the configuration >> file. (/etc/sudoers on my machine) >> ALL=(ALL) ALL >> >> this will allow you to execute any command you want with >> sudo >> but you still don't have to know the root password. The password >> you're providing when executing sudo is yours. > > Let me add another vote for using sudo. Additional advantages are that > one can limit what the sudoer can do, and that it logs (or can be set > to log) all issued commands. (Except that if you allow 'sudo bash' or > some variation, it won't log the session, just that bash started, of > course.). But at least you'll have some audit trail. > > Steve
Re: shared root account
On Fri, Jul 06, 2001 at 09:18:18AM -0400, Jason Healy wrote: > types of > passwords accepted to run root commands, etc). elaborate. the main reason i don't use sudo except for small things which cannot grant a root shell in any way is for the simple reason the sudo converts a normal unprivleged user password into another root password. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpvZtKZdIlLD.pgp Description: PGP signature
Re: shared root account
On 06-Jul-01, 05:34 (CDT), Patrice Neff <[EMAIL PROTECTED]> wrote: > What you want to accomplish might be possible with sudo. Install sudo > and thenn add the following line to the configuration > file. (/etc/sudoers on my machine) > ALL=(ALL) ALL > > this will allow you to execute any command you want with > sudo > but you still don't have to know the root password. The password > you're providing when executing sudo is yours. Let me add another vote for using sudo. Additional advantages are that one can limit what the sudoer can do, and that it logs (or can be set to log) all issued commands. (Except that if you allow 'sudo bash' or some variation, it won't log the session, just that bash started, of course.). But at least you'll have some audit trail. Steve -- Steve Greenland <[EMAIL PROTECTED]> (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: shared root account
At 994443564s since epoch (07/06/01 06:19:24 -0400 UTC), Juha J?ykk? wrote: > I distrust allowing root logins from anywhere but local console(s) > or non-modem gettys i.e. from anywhere over the not-owned-by-me cable. > Any other ideas? Or is it really safe to allow root logins to sshd? > It is just an old rule of thumb that root must never log on over the > wire but that may be old news from times of telnet - never had any > need of root logins over the wire until perhaps now. I agree with others here: use sudo. Even on my own box I use sudo, rather than using my root password. I worked at a company where all the employees had their own linux box. We gave them sudo on their own machines, but only the IT staff had root on the boxes. This way, the staff could do updates (they set up an "admin" account with sudo), and the users could fudge their own configs, but nobody needed actual 'root' to do anything. I do not recommend the UID=0 trick. Too many ways to make typos and hose your passwd file. Also, sudo leaves a nice audit trail, and has many more features that you may find handy in the future (such as the ability to restrict commands run as root, times of day, types of passwords accepted to run root commands, etc). Finally, if you're doing a lot of work and don't want to have to keep typing "sudo" in front of everything, try: sudo -s To get a root shell. Jason -- Jason Healy| [EMAIL PROTECTED] LogN Systems | http://www.logn.net/
Re: shared root account
On Fri, Jul 06, 2001 at 09:29:54AM -0700, Robert L. Yelvington wrote: > admittedly, i am not very familiar with sudo because i have never seen the > practical advantages of making su'ing more of a hassle by having to manage > another set of conf files and keeping track of who's a sudoer and, > therefore, have chosen not to use it. > > what's to stop a person, once they've sudo'd, from editing /etc/sudoers and > giving themselves more privs? [ please avoid jeopardy style quoting ] If sudo already allows a user to run "ALL" commands as root, what privs could they possibly gain? OTOH if you restrict the user to a list of commands in /etc/sudoers, it's wise to consider whether the user might be able to leverage one of those commands to edit /etc/sudoers (or any other file). If you're going to list "emacs" or "vi" in /etc/sudoers, you might as well just list "ALL" :) -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton PGP signature
Re: shared root account
"Robert L. Yelvington" <[EMAIL PROTECTED]> writes: > what's to stop a person, once they've sudo'd, from editing /etc/sudoers and > giving themselves more privs? sudo is to stop them, perhaps? ~Tim -- 15:40:15 up 9 days, 23:50, 12 users, load average: 0.19, 0.04, 0.01 [EMAIL PROTECTED] |The light of the world keeps shining, http://piglet.is.dreaming.org |Bright in the primal glow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
admittedly, i am not very familiar with sudo because i have never seen the practical advantages of making su'ing more of a hassle by having to manage another set of conf files and keeping track of who's a sudoer and, therefore, have chosen not to use it. what's to stop a person, once they've sudo'd, from editing /etc/sudoers and giving themselves more privs? kind regards, ~rob on 7/6/01 6:57 AM, Steve Greenland at [EMAIL PROTECTED] wrote: > On 06-Jul-01, 05:34 (CDT), Patrice Neff <[EMAIL PROTECTED]> wrote: >> What you want to accomplish might be possible with sudo. Install sudo >> and thenn add the following line to the configuration >> file. (/etc/sudoers on my machine) >> ALL=(ALL) ALL >> >> this will allow you to execute any command you want with >> sudo >> but you still don't have to know the root password. The password >> you're providing when executing sudo is yours. > > Let me add another vote for using sudo. Additional advantages are that > one can limit what the sudoer can do, and that it logs (or can be set > to log) all issued commands. (Except that if you allow 'sudo bash' or > some variation, it won't log the session, just that bash started, of > course.). But at least you'll have some audit trail. > > Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Fri, Jul 06, 2001 at 09:18:18AM -0400, Jason Healy wrote: > types of > passwords accepted to run root commands, etc). elaborate. the main reason i don't use sudo except for small things which cannot grant a root shell in any way is for the simple reason the sudo converts a normal unprivleged user password into another root password. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
