Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool,/bin/traceroute
Cmnd_Alias MONITOR = /usr/sbin/iftop, /usr/sbin/iotop
Cmnd_Alias SYSTEM = /sbin/reboot,/sbin/shutdown,/usr/bin/poweroff
Cmnd_Alias SUDOSECURITY = /usr/bin/passwd *,/bin/su,/usr/bin/chattr -* /etc/sudoers,\
/usr/bin/sudo -i , /usr/sbin/useradd ,/usr/sbin/usermod,\
/usr/sbin/userdel,/usr/bin/gpasswd,/usr/bin/groups -*
Defaults !visiblepw
Defaults always_set_home
Defaults env_reset
Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"
Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
root ALL=(ALL) ALL
%sudo ALL=(ALL) ALL
%users ALL=!SUDOSECURITY,!SYSTEM,NOPASSWD:NETWORKING,MONITOR,PASSWD:ALL

how can i define Cmnd_Alias to deny user in users group to use sudo -s or sudo -i to promote to root account

The way to deny it would be to whitelist only the allowed commands. You've got that for some of the aliases, but not all. Remove any attempt at blacklisting. Trying to blacklist can't / won't / doesn't work. Hint: think about hardlinks made from ln or copies made from cp

The best background material for how to use sudo is found in M W Lucas' book sudo Mastery. His presentation "sudo: You're Doing it Wrong" can be found on Youtube and his slides for that are online too. But the book is quite handy and very concise.

1 members found this post helpful.

yes, do not try to blacklist, there can be always another solution to reach their goal. Better to allow only what is really required, and be strict about that.

ok, we are going to deploy a root management system with sudo .
phase one:we want to recycle all root promotion right. but we still allow user to use sudo to excute command except sudo -s or sudo -i.

phase two:we will restrict user to excute limited commands, which is backlist rule .

do you have any solution to avoid use to excute or promote to root account in phase one ?

You still did not understand, it is just meaningless/pointless. If they have any (other) possibility to be root, you are lost. And they definitely have. countless.

Correction regarding phase two:

phase two: we will restrict user to execute limited commands, which is backlist whitelist rule .

Blacklisting cannot, will not, does not work. Perhaps the ultimate example is that a user can always copy a shell to a new file name and then execute that new file as root.

Please see the book mentioned or at least the presentation, some fundamental misunderstandings about sudo need to be cleared up before you can progress.

of course , 100 percent to avoid user to promote to root from technique is impossible, but we can define action policy to tell people do not try to promote to root right with a unconventional way.

with this policy , we at less need to deny user to excute sudo -s or sudo -i to promote to root from technique, because of this two command look like so normal.

when i mean technique , the solution doesn't limit on /etc/sudoers, it can be others .

i search google and find out sudo can be managed by web UI , it need a program, i and saw this https://access.redhat.com/documentat...sudorules.html today , do you know the name of the web ui?

The blacklisting here is pointless, what stops the user doing "sudo /bin/sh"? What stops the user doing "sudo /bin/bash", what stops the user doing "sudo ln -s \bin\bash rootme; sudo rootme" and I could come up with potentially hundreds more ways of getting the same results. Such as 'sudo su -', 'sudo vi /etc/sudoers', 'sudo visudo', etc.

As others have said above, it is preferential to whitelist over blacklist.

Well the whole point of sudo is to switch to root, so it'd be pointless to use sudo if you didn't become root. Thus the 100% way to avoid it is to grant no sudo access at all.

It supports switching to any user, not necessarily only root, though maybe root is most common. You can, for example, use sudo to launch a game server as another unprivileged user. That allows reduced access by the game server, especially if it is a multi-player server.

I meant the purpose of it, that being superuser do. Of course it can run things as different users too, I didn't mean to imply it couldn't.

Ok, you are right too. Just look at the man page of sudo:
And actually the main goal is (here) not to be root, but execute something as not myself.

to OP:
there is no way to do that. I mean there is no such alias.
but obviously you can define a policy to tell people it is not legal.

i know backlisting way to deny user to promote root is pointless, and though phase one is not the end, it is just a transitional period for us,all we want to do in phase one is to make it a little difficult to promote as root. we would like to force user to form some habit which is do not use root to do what it doesn't really neccessary , phase two is our finial target , i hope that you can understand my intention , the example you gave out, they are all violate our excuteion policy and we do have syslog system to account user operations.

so they violate the execution policy right now. And what do you think, will they do that with another set of sudo rules? Certainly yes, if they will find a way. Will another (an even better) policy protect your system? By the way is there any real sanction against them?

you still dont understand , in phase one , i m giving users a sign that we want to restrict root right, it is going to inffluence their operation if they dont change their habit when we change the sudo policy from backlisting to whitelist in phase two. users should care about what is the next.