Re: Security Practices question

[Scott Francis <darkuncle () darkuncle net>]

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

Attachment: _bin
Description: