Re: Security Practices question
On Wed, Oct 02, 2002 at 04:06:00PM -0400, woods@weird.com said:
[ On Wednesday, October 2, 2002 at 11:47:12 (-0700), Scott Francis wrote: ]
Subject: Re: Security Practices question
Absolutely so - which is why no account should have multiple equally valid passwords, which is what multiple accounts sharing a uid equates to.
Hold on a minute. You've taken this entirely out proportion for any reasonable real-world scenario!
that last should have been qualified s/no account should/the root account should not/
It's _NOT_ that bad. Not anywhere near.
The only real risk with having multiple superuser (UID == 0) accounts is when the system has some form of vulnerability which makes it reasonable for an attacker to guess the password. Now normally on any decently modern system the group of potential attackers who could even begin such an attack is limited strictly to those who are already members of the "wheel" group, and all of those people should already have the real root password anyway.
grr. Please read Barb's post about exactly why multiple aliases for the UID 0 account is a Bad Idea. It's not really about opening potential security vulnerabilities as much as it is about bad (lazy) administration.
The risks that a wheel-group member will execute a trojan of some sort that will help an attacker gain increased privileges are much higher than any of the risks directly associated with multiple UID==0 accounts!
Rubbish. There are no risks associated with members of gid 0 that are not also associated with accounts having UID 0 - and multiple accounts with UID 0 brings in a host of other issues and problems.
Different UID==0 accounts can have different home directories, and with careful implementation of certain tools the benefits of this mechanism also vastly outweigh the risks of having multiple UID==0 accounts.
bah. There is _nothing_ one could reasonably hope to accomplish by creating multiple accounts with UID 0 that could not be accomplished at least as easily, and vastly more safely, using sudo. (before anybody uses it as a defense, yes, there are a (very) few systems out there that sudo will not run on. That's not the debate here.)
Even just the benefit of being able to appease multiple human superusers with the abillity to specify different shells for their superuser account can be enough of a benefit to oughtweigh the risks (though of course with a small amount of training in the proper use of 'su', there really isn't any need to specify different default shells in the first place).
su isn't even needed. USE SUDO. I cannot believe that there are so many otherwise clueful people out there that apparently are unfamiliar with the fine-grained control and flexibility that this tool gives the admin (multiple shells, multiple environments, etc. etc. etc.)
You didn't give one solid example of a real-world threat or vulnerability for having multiple superuser (UID == 0) accounts. Not one. If you're going to say something is so bad that nobody should ever do it regardless then you'd better have some damned good solid threat analysis and risk assessment to back up your claim!
Trying to avoid yelling here. PLEASE go read Barb's excellent post on EXACTLY why multiple UID 0 accounts are a problem. She details multiple real risks and problems associated with this practice. I didn't list them because I thought it would surely not be too much to ask for those posting to the thread to READ the thread first, from the beginning. It's not that long.
The only thing you really said that stands up to analysis is your repeated assertion that multiple accounts with the same UID are, from the system's perspective, simply multiple ways to authenticate access to the same underlying system ID and thus to grant exactly the same authorisations. That is 100% true. What this really means, especially if the UID in question is zero(0), is that ultimately all activities that take place on the system are done with that unified UID and so there's no way to hold separate human users accountable for their actions. However in the case of UID==0 that's more or less true of 'su' even with just one "root" account. You have to trust superusers 101%,
I never advocated using su. *sigh* Use sudo.
regardless of how they authenticate to the system. In turn they, if there's more than one of them, must each be held equally responsible for any and all damage done by any superuser. If nobody confesses you can
Yes, there is trust that must be given along with superuser privs. The level of trust required can be MUCH LOWER using sudo, ACLs, or some other system. As opposed to just giving $admin or $user a blank check to do whatever they please. There was an excellent talk on exactly why the UNIX permissions scheme is archaic and needs to be replaced at ToorCon last weekend <http://www.toorcon.org>, but this is getting off-topic (even for this thread).
point fingers just as easily with 'login' logs as you can with 'su' logs, but in the end you cannot prove anything with those logs alone if its UID==0 (unless the logging is done securely in such a way that UID==0 cannot modify it). The finger pointing suggested by the logs _MUST_ be corroberated with an external verifiable alibi (or hopefully multiples!) (which, BTW, is essentially what any secure logging system is, and it doesn't matter if 'login' or 'su' generates the audit trail).
USE SUDO. Most people, even those with a legitimate need for superuser privileges, do not really need the ability to do EVERYTHING on the system as UID 0. Sure, it takes a bit more effort to setup, but I don't think anybody could argue that the gains in control, logging, security and authentication/authorization are not worth it.
Use sudo, use ssh keys from a central admin host, use ACLs - use whatever you like, but please don't create multiple aliases for an account and think it's anything but an invitation to disaster.
Sudo is a far worse solution, with a far higher false sense of security, than multiple UID==0 accounts, unless maybe you're using it purely and only for convenience and documentation purposes amongst a group of mutually trusting users who already each know the "real" root password anyway.
Can you back up that statement in /any/ way? What exactly are your reasons why sudo is a worse solution (or even a bad idea)? -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui
On Wed, 2 Oct 2002, Scott Francis wrote: Can you back up that statement in /any/ way? What exactly are your reasons why sudo is a worse solution (or even a bad idea)? In an environment where every sysadmin is interchangable, and any one of them can be woken up at 3am to fix the random problem of the day, you tell me how to manage 'sudoers' on 4000 machines. In an situation where the team needs root; all per-admin UID 0 accounts add is accountability and personalized shells/environments. Sorry to ruffle your dogma. --mghali@snark.net------------------------------------------<darwin>< Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include <disclaim.h>
jm> Date: Wed, 2 Oct 2002 17:48:16 -0700 (PDT) jm> From: just me jm> In an environment where every sysadmin is interchangable, and jm> any one of them can be woken up at 3am to fix the random jm> problem of the day, you tell me how to manage 'sudoers' on jm> 4000 machines. krb5/ksu Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
On Wed, 2 Oct 2002, just me wrote:
In an environment where every sysadmin is interchangable, and any one of them can be woken up at 3am to fix the random problem of the day, you tell me how to manage 'sudoers' on 4000 machines.
In an situation where the team needs root; all per-admin UID 0 accounts add is accountability and personalized shells/environments.
Sorry to ruffle your dogma.
Have I missed something here? It seems to me having multiple uid 0's would do no good. Can't a UID 0 user change the password of any other user. Wouldn't a malicious uid 0 user just change the regular root password? How does this add any additional layer of accountability. A uid 0 user can erase the logfiles, unless they are immutable and you are in secure mode. Jason -- Jason Slagle - CCNP - CCDP /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail .
On Wed, Oct 02, 2002 at 05:48:16PM -0700, just me wrote:
On Wed, 2 Oct 2002, Scott Francis wrote:
Can you back up that statement in /any/ way? What exactly are your reasons why sudo is a worse solution (or even a bad idea)?
In an environment where every sysadmin is interchangable, and any one of them can be woken up at 3am to fix the random problem of the day, you tell me how to manage 'sudoers' on 4000 machines.
rdist comes to mind... -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
could use scp also. Altho not as secure you'd need null keys. But could also have the same issues with rdist. Joel Baker wrote:
On Wed, Oct 02, 2002 at 05:48:16PM -0700, just me wrote:
On Wed, 2 Oct 2002, Scott Francis wrote:
Can you back up that statement in /any/ way? What exactly are your reasons why sudo is a worse solution (or even a bad idea)?
In an environment where every sysadmin is interchangable, and any one of them can be woken up at 3am to fix the random problem of the day, you tell me how to manage 'sudoers' on 4000 machines.
rdist comes to mind...
On Wed, 02 Oct 2002 17:48:16 PDT, just me said:
In an situation where the team needs root; all per-admin UID 0 accounts add is accountability and personalized shells/environments.
Accountability is always good, but you can do even better with sudo (Sorry, I couldn't resist). As far as personalized shells/environments go, I've found that this helps a lot: export ENV=~/.kshrc (for ksh-based systems) export BASH_ENV=~/.bashrc (for bash-based boxes) su -m (or whatever "save the environment" parameter your su has) and voila, you have your preferred environment. Bottom line - per-admin UID 0 doesn't give you anything you couldn't get via other means. (And please, no flames about using su rather than sudo, or the wisdom of using su and preserving the environment - I've already done the analysis and decided it's correct *for the machines in question*.) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
On Wed, Oct 02, 2002 at 05:48:16PM -0700, matt@snark.net said:
On Wed, 2 Oct 2002, Scott Francis wrote:
Can you back up that statement in /any/ way? What exactly are your reasons why sudo is a worse solution (or even a bad idea)?
In an environment where every sysadmin is interchangable, and any one of them can be woken up at 3am to fix the random problem of the day, you tell me how to manage 'sudoers' on 4000 machines.
You don't _have_ logins directly to 4000 machines. You have a central admin host (or five) with user-level accounts. Those user-level accounts can 'sudo ssh <target>' to accomplish things as root on the remote boxes. Given the nature of the UNIX permissions structure, any solution is going to be lacking when scaled up large enough - but the problems involved in properly administering sudo are considerly smaller than those introduced by having mulitple uid 0 accounts (especially multiple uid 0 accounts on multiple machines). What do you do when one (or ten) of those 'interchangeable syadmins' leaves the company? _Then_ you have a real nightmare - changing root and removing uid 0 accounts on 4000 boxes. I'd rather manage /etc/sudoers, thanks very much.
In an situation where the team needs root; all per-admin UID 0 accounts add is accountability and personalized shells/environments.
All of which can be handled with sudo, without giving away the keys to the castle.
Sorry to ruffle your dogma.
Not dogma, just best practice. -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui
On Thu, 3 Oct 2002, Scott Francis wrote: On Wed, Oct 02, 2002 at 05:48:16PM -0700, matt@snark.net said:
In an environment where every sysadmin is interchangable, and any one of them can be woken up at 3am to fix the random problem of the day, you tell me how to manage 'sudoers' on 4000 machines.
You don't _have_ logins directly to 4000 machines. You have a central admin host (or five) with user-level accounts. Those user-level accounts can 'sudo ssh <target>' to accomplish things as root on the remote boxes. So you propose that a trust relationship over the network is a more secure solution? I can't believe you're advocating allowing ssh logins as root as a better idea than per-admin uid 0 accounts. Given the nature of the UNIX permissions structure, any solution is going to be lacking when scaled up large enough - but the problems involved in properly administering sudo are considerly smaller than those introduced by having mulitple uid 0 accounts (especially multiple uid 0 accounts on multiple machines). You still haven't given me a single example of what these "problems" are. Just hand-waving and talk about the "right" way is. What do you do when one (or ten) of those 'interchangeable syadmins' leaves the company? _Then_ you have a real nightmare - changing root and removing uid 0 accounts on 4000 boxes. I'd rather manage /etc/sudoers, thanks very much. Are you paying attention? If one of the admins leave, his accounts (user and UID 0) are deactivated. The password on the "root" account doesn't need to be changed, assuming he/she didn't know it. Where's the nightmare there? Its the same level of effort that managing the sudoers file. If thats a nightmare in your environment, I'm sorry, you've got bigger problems.
In an situation where the team needs root; all per-admin UID 0 accounts add is accountability and personalized shells/environments.
All of which can be handled with sudo, without giving away the keys to the castle. An open sudo configuration (which Barb is advocating in her latest post) gives away those same keys. So I don't see what the benefit here is. matto --mghali@snark.net------------------------------------------<darwin>< Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include <disclaim.h>
On Thu, Oct 03, 2002 at 09:57:10AM -0700, matt@snark.net said:
On Thu, 3 Oct 2002, Scott Francis wrote:
On Wed, Oct 02, 2002 at 05:48:16PM -0700, matt@snark.net said:
In an environment where every sysadmin is interchangable, and any one of them can be woken up at 3am to fix the random problem of the day, you tell me how to manage 'sudoers' on 4000 machines.
You don't _have_ logins directly to 4000 machines. You have a central admin host (or five) with user-level accounts. Those user-level accounts can 'sudo ssh <target>' to accomplish things as root on the remote boxes.
So you propose that a trust relationship over the network is a more secure solution? I can't believe you're advocating allowing ssh logins as root as a better idea than per-admin uid 0 accounts.
Absolutely. Make logins restricted to a specific host or hosts, key-based auth only ... heck, put a private NIC on each box and make it so that sshd only binds to an RFC1918 address. You think multiple uid zero accounts on each box is more secure than this? Or worse, easier to manage?
Given the nature of the UNIX permissions structure, any solution is going to be lacking when scaled up large enough - but the problems involved in properly administering sudo are considerly smaller than those introduced by having mulitple uid 0 accounts (especially multiple uid 0 accounts on multiple machines).
You still haven't given me a single example of what these "problems" are. Just hand-waving and talk about the "right" way is.
I thought the comment below would have illustrated the potential management nightmare introduced by having multiple uid zero accounts per machine. If it did not, I don't know how to make it any more clear.
What do you do when one (or ten) of those 'interchangeable syadmins' leaves the company? _Then_ you have a real nightmare - changing root and removing uid 0 accounts on 4000 boxes. I'd rather manage /etc/sudoers, thanks very much.
Are you paying attention? If one of the admins leave, his accounts (user and UID 0) are deactivated. The password on the "root" account
YES - but deactivated on EACH of 4000 boxes?!
doesn't need to be changed, assuming he/she didn't know it. Where's
He/she ALREADY HAD IT! What multiple uid zero accounts amounts to is multiple equally valid passwords for the SAME ACCOUNT. When somebody has root, and they leave, anybody with enough sense to _be_ a sysadmin immediately changes /all/ root-level accounts and accesses in the network, anywhere the ex-employee had access. To do otherwise is foolhardy at best.
the nightmare there? Its the same level of effort that managing the sudoers file. If thats a nightmare in your environment, I'm sorry, you've got bigger problems.
managing sudoers across a network is dead simple - either use a central, tightly-controlled admin host/hosts, or else use rsync+ssh keys to propagate changes.
In an situation where the team needs root; all per-admin UID 0 accounts add is accountability and personalized shells/environments.
All of which can be handled with sudo, without giving away the keys to the castle.
An open sudo configuration (which Barb is advocating in her latest post) gives away those same keys. So I don't see what the benefit here is.
I don't think anybody ever advocated an open config - I, at least, think ALL=(ALL) ALL offers few benefits over simply handing out the root password (which is still less troublesome than creating multiple root-level accounts). I personally think the best practice is default deny - take away _everything_, and then add only what is really needed. A case should be made for every superuser ability that is requested. (anyway, I promised I'd stop with this thread. If you're interested in debating this issue further, I'll be happy to do so off-list.) regards, -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui
You still haven't given me a single example of what these "problems" are. Just hand-waving and talk about the "right" way is.
It is rather simple and had been addressed lots of times. I really fail to understand why people do keep re-inventing the wheel. Give your admins crypto cards. Make sure that crypto-card service talks GSS-API. Have a GSS-API service provider Configure all your systems to use GSSAPI interface. So, why are we re-inventing the wheel again? Alex P.S. Dont claim that crypto cards are expensive. If you have 40000 Unix machines, you can AFFORD to give everyone a crypto card.
"Scott" == Scott Francis <darkuncle@darkuncle.net> writes:
Scott> You don't _have_ logins directly to 4000 machines. You have Scott> a central admin host (or five) with user-level Scott> accounts. Those user-level accounts can 'sudo ssh <target>' Scott> to accomplish things as root on the remote boxes. umm... i think you have it backwards. better would be: the admins have logins on the remote machines, with no local password and rsa keys disabled. the remote machines trust the admin machines and do host based authentication. most admins may or may not have root on the admin machine. admins have normal user accounts on the admin box. sudo is set up on the remote ones. admin then does 'ssh foobar sudo blah' to accomplish something as root on the remote boxes without loggin in as directly as root. ever. (for a remote root shell, 'ssh -t foobar sudo su -' or similar) the main difference is it leaves an audit trail of who is doing what where as root -- with 4000 machines, you are doing remote logging, no? Scott> All of which can be handled with sudo, without giving away Scott> the keys to the castle. >> Sorry to ruffle your dogma. Scott> Not dogma, just best practice. since when does best practice entail logging in directly as root over the network? -- William Waites <ww@styx.org> Idiosyntactix Research Laboratories http://www.irl.styx.org
participants (9)
-
alex＠yuriev.com -
E.B. Dreger -
Jason Slagle -
Joel Baker -
just me -
Scott Francis -
Scott Walker -
Valdis.Kletnieks＠vt.edu -
William Waites