Block Particular Command in Linux for Specific user

Question

How to block command, let say mkdir for specific user ?

What I did just created read-only function and store in users profile ~/.bashrc

/bin/mkdir() {
        echo "mkdir command not allow for you"

}

mkdir() {
        echo "mkdir command not allow for you"

}
./mkdir() {

        echo "mkdir command not allow for you"
}

readonly -f /bin/mkdir
readonly -f mkdir
readonly -f ./mkdir

Test:

rahul@ubuntu:~$ cd /bin/
rahul@ubuntu:/bin$ ./mkdir /home/rahul/ggg
mkdir command not allow for you
rahul@ubuntu:/bin$ cd
rahul@ubuntu:~$ mkdir testing
mkdir command not allow for you
rahul@ubuntu:~$ /bin/mkdir testing
mkdir command not allow for you

So my question is What should be the way of achieving this ? is there any tool for this ?

Update 1 # But if user is smart , he could copy mkdir binary and rename it and use it . So how to achieve this ?

Your example will fail because the user could compile his own `mkdir` and rename it, or even just copy and rename the existing binary. Also, there's a shell builtin for overriding aliases and functions. — strugee, Sep 17 '13 at 07:05
also user don't need to compile he can easily copy `cp /bin/mkdir mkdir2` then use it :( — Rahul Patil, Sep 17 '13 at 07:08
Creating a directory is such a common/fundamental task that there are multiple ways of doing it, and it would be almost impossible to block them all (except by not letting the user create files; i.e., write-protecting all directories against him). For example, `cp -r /usr/local/lib ggg` will create a directory called `ggg` (containing a copy of the contents of `/usr/local/lib`, if any, which the user can then just delete). You can use `find / -type d -empty` to find an empty directory to copy. — G-Man Says 'Reinstate Monica', Aug 21 '15 at 07:19

score 21 · Accepted Answer · edited Sep 18 '13 at 08:45

21

I don't know how to do it with bash, but I know of another shell that restricts the user environment: lshell (limited shell).

A quick overview of configuration

Lshell is configured via an INI file. By default, it holds a whitelist of allowed commands, but it can be easily configured to prohibit user from using a specific command.

This configuration (default conf /etc/lshell.conf) prohibits user foo from using mkdir:

[foo]
allowed = 'all' - ['mkdir', 'bash', 'sh', 'csh', 'dash', 'env']

In order to configure a user account to use lshell by default, you must:

 chsh -s /usr/bin/lshell foo

Lshell can do more, like:

3 levels of granularity: user, group, all.
Can restrict access to certain paths in the system.
Can restrict the use of certain characters (like |).
Can restrict the use of certain commands only over SSH.

And more.

Update 1# Added Test Result :

rahul:~$ which bash
/bin/bash
rahul:~$ dd if=$(which bash) of=my_bash
*** forbidden syntax: dd if=$(which bash) of=my_bash
rahul:~$ bash
*** forbidden command: bash
rahul:~$ cp /bin/bash my_bash
*** forbidden path: /bin/bash
rahul:~$ /bin/bash
*** forbidden command: /bin/bash
rahul:~$ sh
*** forbidden command: sh
rahul:~$ dash
*** forbidden command: dash
rahul:~$ env bash
*** forbidden command: env
rahul:~$ cp /bin/mkdir mycreatedir
*** forbidden path: /bin/mkdir

edited Sep 18 '13 at 08:45

Rahul Patil

24,281
25
80
96

answered Sep 17 '13 at 07:20

rahmu

19,673
28
87
128

3

with `allowed = 'all' - ['mkdir']`, can't you just execute `bash` and be unrestricted again? – dawud Sep 17 '13 at 07:54
@dawud you are correct, so I had modified entry to `allowed = 'all' - ['mkdir', 'bash', 'sh', 'csh', 'dash', 'env']` – Rahul Patil Sep 17 '13 at 08:36
3

Just being pedantic, sorry, but there are still a lot of ways to circumvent the restrictions imposed by that list, e.g. `dd if=$(which bash) of=my_bash && chmod u+x my_bash && ./my_bash`. I think the problem is the lack of a restrictive default policy, i.e., in this scenario you GRANT permissions by default, then DENY permissions based on a list, when it should be the other way around: DENY by default, then GRANT based on policy. – dawud Sep 17 '13 at 08:48
1

@dawud: I agree that maintaining a whitelist of allowed commands is a better approach than having a blacklist and hoping the user won't circumvent it by out-clevering the admin. – rahmu Sep 17 '13 at 09:19
1

What is the difference of using a whitelist? You can still copy `bash` to `ls` and launch your shell as `ls`, or any other whitelisted command for that matter. – Marco Sep 17 '13 at 10:03
2

@Marco, check the example provided in my answer. I provide a whitelist of allowed commands, and in that scenario, the user cannot just `cp` a binary to his/her PATH (`root` owned directory, `rx` for the user), and `rbash` prevents from executing `./executables`. Does it answer your question? – dawud Sep 17 '13 at 13:01
2

@dawud It does, indeed. I missed the read-only bin directory. – Marco Sep 17 '13 at 13:05
1

@Marco and dawud I have added tested scenario – Rahul Patil Sep 18 '13 at 08:45
Thanks! I have created a user with basic permissions & commands available using this on my old netbook (now network attached storage) , so i can use [ssh button](https://play.google.com/store/apps/details?id=com.pd7l.sshbutton&hl=en) on my phone in case of security flaws. – Wilf Jan 04 '15 at 01:34

dawud · Answer 2 · 2013-09-17T13:03:26.353

The way I usually implement this kind of restrictions requires that several conditions are met, otherwise the restriction can be easily circumvented:

The user does not belong to the wheel group, the only one authorized to use su (enforced via PAM).

The user is given a properly secured rbash with a read-only PATH pointing to a private ~/bin, this ~/bin/ directory contains links to simple utilities:

$ ll ~/bin
total 0
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
lrwxrwxrwx. 1 root dawud  7 Sep 17 08:58 df -> /bin/df*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
lrwxrwxrwx. 1 root dawud  8 Sep 17 08:58 env -> /bin/env*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
lrwxrwxrwx. 1 root dawud  9 Sep 17 08:58 grep -> /bin/grep*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 rvim -> /usr/bin/rvim*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*

the user is given a restricted, read-only environment (think of stuff like LESSSECURE, TMOUT, HISTFILE variables).
the user is mapped to the SELinux user staff_u and given rights to execute commands as other user as required via sudo.

the user's /home, /tmp and possibly /var/tmp are polyinstantiated via /etc/security/namespace.conf:

/tmp       /tmp/.inst/tmp.inst-$USER-     tmpdir:create   root
/var/tmp   /tmp/.inst/var-tmp.inst-$USER- tmpdir:create   root
$HOME      $HOME/$USER.inst/              tmpdir:create   root

Also, /etc/security/namespace.init makes all skeletal files readonly for the user and owned by root.

This way you can choose whether $USER can execute mkdir on his/her own behalf (via a link in the private ~/bin directory, provisioned via /etc/skel, as explained above), on behalf of other user (via sudo) or none at all.

score 4 · Answer 3 · answered Sep 17 '13 at 07:14

4

Add a dummy group, add the user to that group, chown root:somegroup /bin/mkdir, chmod g-x /bin/mkdir. Note that this relies on the user not being able to modify their groups. IIRC this is true in GNU/Linux but not in some other Unices.

answered Sep 17 '13 at 07:14

strugee

14,723
17
73
119

2

On most filesystems you can also use extended ACLs for finer grained control - the number of groups needed would grow exponentially with the number of users (due to possible combinations), not to mention the naming problems. – peterph Sep 17 '13 at 07:19
2

add one more point, also remove read permission from other users 710, so user could not copy and rename that binary isn't it ? – Rahul Patil Sep 17 '13 at 07:20
1

@RahulPatil yes, and of course you need to restrict their use of a compiler as well. – peterph Sep 17 '13 at 07:21

score 1 · Answer 4 · edited Apr 21 '16 at 15:17

1

The best as i have tested is to use Profile.d best & safest way

Step # 1 (Create a Alias File)

[root@newrbe ~]# vim /etc/customalias.sh

Add Below lines :

alias rm="echo remove contenet is restricted"
alias poweroff="echo Poweroff is restricted"
alias chmod="echo Change Permission is restristed"

Save & quit

Step # 2 (Create Profile loader)

/etc/profile.d/ this location contains files for bash completion

[root@newrbe ~]# vim /etc/profile.d/customsource.sh

Add below lines under the files these lines will block mentioned commands for below users

if [ `whoami` == "user1" ] && [ `whoami` == "user2" ]; then
    source /etc/customalias.sh
fi

save and quit

Now Exit and relogin

Regards, -Mansur

edited Apr 21 '16 at 15:17

Stéphane Chazelas

522,931
91
1,010
1,501

answered Apr 21 '16 at 15:11

Mansur Ul Hasan

277
3
4

`/etc/profile.d/` is not for _`bash` completion_, it's where to place login session customisations for users using POSIX-like login shells, so it's typically not where `bash` alias customisations (which would rather go in `/etc/bash.bashrc`) would go and it should have a POSIX shell syntax (so typically, `.` instead of `source` and `=` instead of `==`). – Stéphane Chazelas Apr 21 '16 at 15:23

score -1 · Answer 5 · answered Sep 18 '13 at 12:00

-1

install sudoers and try to configure there whose users and what command.

answered Sep 18 '13 at 12:00

mark.praktisero

11

4

Welcome to SX. Please add details to your answer; the OP, or anyone else reading this question in the future, may not be aware of `sudo`. – Joseph R. Sep 18 '13 at 12:21
1

This answer is just plainly wrong – kiltek Mar 08 '18 at 09:26

Block Particular Command in Linux for Specific user

5 Answers5

Step # 1 (Create a Alias File)

Step # 2 (Create Profile loader)

Linked

Related