Re: difference of opinion re: Sudo and security - 2 approaches

• Previous message: Security Alert: "SSRT051023 rev.4 - HP OpenView Network Node Manager (OV NNM) Remote Unauthorized Privileged Access"
• In reply to: Manager: "difference of opinion re: Sudo and security - 2 approaches"
• Next in thread: jpd: "Re: difference of opinion re: Sudo and security - 2 approaches"
• Reply: jpd: "Re: difference of opinion re: Sudo and security - 2 approaches"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Mon, 19 Sep 2005 20:25:28 +0200

Manager <Manager_member@newsguy.com> wrote:

> The applications group needs the ability to run a few things with higher
> privileges, e.g. need to be able to start and stop apache, and a number of
> other things, hence the need for sudo. In the past they have had the root
> password, and would su to root directly when higher priviledges were required,
> and then back down to the relevant application account.
>
> The systems admin group wants the application group to log onto the machines
> (apps groups come in on the same subnet which is switched) using named
> accounts e.g. based on their personal id (e.g. jbrown), then sudo su to the
> application
> accounts as required. They have indicated that they wish the only the web
> account (which owns and runs apache out to the public) to be the only account
> that can sudo ALL under the concept of least priviledge. The indicate that
> they are concerned about giving sudo ALL priviledge to the personal accounts
> for the applications group in case that account is compromised.

The web account SHOULD NOT be able to sudo to anything but a helper script
controlled by yourself. Anything else would be too dangerous.

You can assign a password for a user group (e.g. webmaster). The newgrp
command will ask for a password if the user is not part of that group and
provide a shell with access to that group. You can allow only this group to
e.g.execute sudo /etc/init.d/apache {start,stop}.

If you do this, the webmasters will still be logged by name but if one
of their accounts is compromised, it will not grant immediate system
access. However, if I 0wn3d one of these webmaster accounts, I'd install
a customized sudo in ~/bin. Using a dedicated webmaster account would still
be worse since everybody would know the password.

There's still a problem: What do you do if a webmaster is downsized?
You'll probably need to put all webmasters into a second group and
add another group check either to the configuration or to a wrapper script.

BTW:
I'm using su1 instead of sudo, mostly because it's easier to find, compile
and configure su1 than to read the first paragraph of the sudo manual and
partly because it is much leaner and I had less google hits with
'exploit su1' than with 'exploit sudo' when I searched for a su tool.

(With su1, you'll need a non-webmaster group and use
 "refuse *.nowebmaster ...\n allow webmaster ...")

Since su1 is _very_ hard to find: http://www.canb.auug.org.au/~dbell/

-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

• Previous message: Security Alert: "SSRT051023 rev.4 - HP OpenView Network Node Manager (OV NNM) Remote Unauthorized Privileged Access"
• In reply to: Manager: "difference of opinion re: Sudo and security - 2 approaches"
• Next in thread: jpd: "Re: difference of opinion re: Sudo and security - 2 approaches"
• Reply: jpd: "Re: difference of opinion re: Sudo and security - 2 approaches"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]