[sudo-users] Disabling "sudo su" but allow everything else?

[Kevin Shortt]

I would agree with Patrick.


There are 1000's of end runs around becoming root by your approach.  This
approach can only be enforced with policy and monitoring access to the root
account.  If you're allowing sudo to do anything but become root by "sudo su
-" and shells, then you have basically said every action is acceptable as
long as we can track what you are doing.

Put that in policy, and reprimand all that execute "sudo su -".   This
approach only works when properly enforced.

My two cents.

-Kevin



On Mon, Aug 2, 2010 at 6:35 PM, Parson, David <
David.Parson at integratelecom.com> wrote:

> Enable the "visudoers" version of 'vi' which is a re-coded vi that will
> only vi sudoers, and will not exit to shell.  However allowing those not in
> the root group (e.g. everyone in the sudoers) to edit sudoers is somewhat
> pointless since they can edit the file and change it/ change it back.
>
>
>
>
>
> -----Original Message-----
> From: sudo-users-bounces at courtesan.com [mailto:
> sudo-users-bounces at courtesan.com] On Behalf Of Patrick Spinler
> Sent: Monday, August 02, 2010 1:34 PM
> To: Paul Cantle
> Cc: sudo-users at sudo.ws; Jimmy Crackcorn
> Subject: Re: [sudo-users] Disabling "sudo su" but allow everything else?
>
> On 08/02/2010 02:14 PM, Paul Cantle wrote:
> > Hi All,
> >
> > I'd also look to disable /bin/vi (without the /etc/sudoers flag by adding
> it to the RESTRICTED alias) as users will be able to shell out of vi by
> default and get a root shell anyway (which will kind of make !SHELLS
> irrelevant).
> >
>
> Be careful, this way madness lies.
>
> Remember there's many programs that can spawn a shell, Some pages such
> as less for instance.  Certain editors (vi and emacs) and mail handlers.
>  The list goes on and on.
>
> You'll either find yourself missing stuff, or rapidly back yourself into
> a corner.
>
> Worse, even if you catch all the system installed exceptions, *nothing*
> prevents a user from doing:
>
>   cp /bin/sh_of_choice  /some/writeable/directory/whee_i_have_privs
>   sudo /some/writeable/directory/whee_i_have_privs
>
> A much better approach is to deny everything by default, and selectively
> grant the few privs the user really needs.  For instance, here's a setup
> I might do on redhat for an apache server:
>
> @group_to_priv          ALL=(root)      /sbin/service httpd *
> @group_to_priv          ALL=(root)      sudoedit /etc/http.d/*.conf
> @group_to_priv          ALL=(root)      /sbin/su - apache
>
> -- Pat
>
> ____________________________________________________________
> sudo-users mailing list <sudo-users at sudo.ws>
> For list information, options, or to unsubscribe, visit:
> http://www.sudo.ws/mailman/listinfo/sudo-users
> ____________________________________________________________
> sudo-users mailing list <sudo-users at sudo.ws>
> For list information, options, or to unsubscribe, visit:
> http://www.sudo.ws/mailman/listinfo/sudo-users
>