28

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 ?

Improve this question
4
  • 7
    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. Commented Sep 17, 2013 at 7:05
  • hmm that's correct , so is there anyway ? Commented Sep 17, 2013 at 7:07
  • also user don't need to compile he can easily copy cp /bin/mkdir mkdir2 then use it :( Commented Sep 17, 2013 at 7: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. Commented Aug 21, 2015 at 7:19

5 Answers 5

Reset to default
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
Improve this answer
9
  • 3
    with allowed = 'all' - ['mkdir'], can't you just execute bash and be unrestricted again? Commented Sep 17, 2013 at 7:54
  • 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. Commented Sep 17, 2013 at 8: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. Commented Sep 17, 2013 at 9:19
  • 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? Commented Sep 17, 2013 at 13:01
  • 2
    @dawud It does, indeed. I missed the read-only bin directory. Commented Sep 17, 2013 at 13:05
15

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.

Improve this answer
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.

Improve this answer
3
  • 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. Commented Sep 17, 2013 at 7: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 ? Commented Sep 17, 2013 at 7:20
  • 1
    @RahulPatil yes, and of course you need to restrict their use of a compiler as well. Commented Sep 17, 2013 at 7:21
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

Improve this answer
2
  • /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 ==). Commented Apr 21, 2016 at 15:23
  • Users could usse the full path of applications, ex: /usr/bin/rm, to circumvent this. Commented Apr 25, 2024 at 23:54
-1

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

Improve this answer
2
  • 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. Commented Sep 18, 2013 at 12:21
  • 1
    This answer is just plainly wrong Commented Mar 8, 2018 at 9:26

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.