sudo: blocking specific commands

UNIX for Advanced & Expert Users
1

Hello all,

I manage some HP-UX 11.31 servers. I have some users that have sudo access. All of them belong to the 'sudoers' user group. Right now, sudo is configured as wide open:

%sudoers ALL=(ALL) ALL

We are using sudo mostly for auditing purposes - when a user wants to run a privileged command, I want to see exactly what they are doing in syslog.

I have some sneaky users however who are running '/usr/sbin/smh' and also just 'su -' to gain a root shell. I don't like this because I cannot see what they're doing.

What lines can I add to the /etc/sudoers file to block this group from running these commands? I have googled and found lots of examples of allowing a specific list of commands and blocking everything else, but I want the opposite; I want to allow sudoers to run any commands they like, except for the few I specify on my "block list".

Does someone know how I can implement this?

Thank you

2

The problem is the use of "default permit". Like in a firewall, this opens not just a security hole but all possible security holes. Whenever they think of a new way to get root shells you haven't thought of, they will be able to do it.

Block everything by default. Remove the allow-everything sudo rule. The only holes in the configuration will be ones you open.

Then make individual sudo rules to allow only the few things they actually need.

3

Thank you for the reply,

Yes I realize that from a security standpoint, your recommendation is the best approach. I'm the senior HP-UX admin here, and all the users that have sudo access are Junior admins, so we're all on the same team. The Junior admins really need to have access to just about everything that root can do, because they need to manage things when I'm out on vacation or whatever, and they need to try things on their own and learn the systems. These are dev & test servers, not production.

I trust them not to break things (too much), I just want there to be an audit trail of who ran what and when, when it comes to privileged commands.

A black list of just a hand ful of items is sure easier to manage than a white list with thousands of things on it.

So yes I understand your recommendation, but in my particular situation, it isn't of great concern if they find another way to get a root shell, I'll just add it to the black list. These Jr. admins aren't super savy hacker types, they mostly just use google and try the first 2 or 3 things they come across. :slight_smile:

4

I fear you are faced with the problem of stopping root from being root, but blacklists appear to be possible using aliases, though they're not called blacklists because you can't say "permit everything" then add another rule saying "...except this". It would end up as more of a "permit everything but this" rule.

Modifying an example from my linux system's man sudoers:

# From 'man sudoers'
Cmnd_Alias     SU = /usr/bin/su
Cmnd_Alias     SHELLS = /usr/bin/sh, /usr/bin/csh, /usr/bin/ksh, \
                                /usr/local/bin/tcsh, /usr/bin/rsh, \
                                /usr/local/bin/zsh

# jill may run any commands in the directory /usr/bin/ except for those
# commands belonging to the SU and SHELLS Cmnd_Aliases.
jill           ALL = /usr/bin/, !SU, !SHELLS
1 Like
5

Perfect, thank you. :b:

6

This example works perfectly unless there's a copy/link of /bin/vi in /usr/bin/ directory. Just execute sudo /usr/bin/vi. Press ESC and type :!/bin/sh and bam!! You get a root shell!! :smiley:

Just recheck if there's anything in /usr/bin directory that can let you escape to shell. If so, make a separate command alias to deny explicitly. :b:

7

For that matter, they could always try the sledgehammer approach:

sudo cp /bin/sh /usr/bin/freakazoid ; sudo /usr/bin/freakazoid

..and if you can't let them have cp, what can they have?

You're still stuck trying to stop root from being root.

8

Are you sure this is working for you with a user which has /etc/sudoers entry similar to what you posted?

Because, it does not work for me (which is a good sign) with the similar setup:

[testuser@blue testuser]$ sudo cp /bin/sh /usr/bin/blahblah
[sudo] password for testuser:
Sorry, user testuser is not allowed to execute '/bin/cp /bin/sh /usr/bin/blahblah' as root on blue.
[testuser@blue testuser]$

Although my knowledge is limited to AIX, Solaris and Linux, I have seen vi to appear in /usr/bin as well in some systems. That's the reason I was concerned and felt obligated to inform the OP about this.

9

One would be able to circumvent this by using setuid and a small c program to call shell script with only /usr/bin/ksh in it.

That would result in ksh shell with root.
Tools are gcc (not sudoed) and (sudo) chown/chmod

10

Excellent catch!!

But, Corona has given a solid example here. As /bin is not listed as permitted and as permit ALL is not specified, the default behavior of sudo would be to deny access. As chmod/chown appears in /bin the user will not be able to execute them with sudo. Also, user cannot copy or link chmod or chown to /usr/bin (the only permitted directory) as again cp appears in /bin directory also /usr/bin has root as the owner, so no write permission for the user. The user is trapped well. :smiley: