Блок Конкретная Команда в Linux для Определенного пользователя

Я использую YumExtender. Вот являются инструкции по загрузке fron сайтом, включая .repo файл:

"Пакеты расположены в repo: http://repos.fedorapeople.org/repos/timlau/yumex/

  1. загрузите .repo файл
  2. Скопируйте его в/etc/yum.repos.d/как корень
  3. установите его со вкусным yumex-будущим установки как корень"

27
18.09.2013, 00:51
5 ответов

Я не знаю, как сделать это с ударом, но я знаю о другой оболочке, которая ограничивает пользовательскую среду: lshell (ограниченная оболочка).

Быстрый обзор конфигурации

Lshell настроен через файл INI. По умолчанию это содержит белый список позволенных команд, но это может быть легко настроено, чтобы мешать пользователю использовать определенную команду.

Эта конфигурация (значение по умолчанию conf /etc/lshell.conf) запрещает пользователя foo от использования mkdir:

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

Для конфигурирования учетной записи пользователя для использования lshell по умолчанию, Вы должны:

 chsh -s /usr/bin/lshell foo

Lshell может сделать больше, как:

  • 3 уровня гранулярности: пользователь, группа, все.
  • Может ограничить доступ к определенным путям в системе.
  • Может ограничить использование определенных символов (как |).
  • Может ограничить использование определенных команд только по SSH.

И т.д.

Обновление 1# добавленный результат испытаний:

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
21
27.01.2020, 19:39
  • 1
    с allowed = 'all' - ['mkdir'], не можете Вы просто выполниться bash и будьте неограниченны снова? –  dawud 17.09.2013, 10:54
  • 2
    Просто будучи педантичным, извините, но существует все еще много способов обойти ограничения, введенные тем списком, например. dd if=$(which bash) of=my_bash && chmod u+x my_bash && ./my_bash. Я думаю, что проблемой является отсутствие строгой политики по умолчанию, т.е. в этом сценарии Вы ДАЕТЕ разрешения по умолчанию, затем ОТКЛОНЯЕТЕ полномочия на основе списка, когда это должно быть наоборот: ОТКЛОНИТЕ по умолчанию, затем ПРЕДОСТАВЬТЕ на основе политики. –  dawud 17.09.2013, 11:48
  • 3
    @dawud: Я соглашаюсь, что поддержание белого списка позволенных команд является лучшим подходом, чем наличие черного списка и надежда, что пользователь не обойдет его-clevering администратором. –  rahmu 17.09.2013, 12:19
  • 4
    @Marco, проверяют пример, обеспеченный в мой ответ. Я предоставляю белый список позволенных команд, и в том сценарии, пользователь не может просто cp двоичный файл к его ПУТИ (root находящийся в собственности каталог, rx для пользователя), и rbash препятствует выполниться ./executables. Это отвечает на Ваш вопрос? –  dawud 17.09.2013, 16:01
  • 5
    @dawud Это делает, действительно. Я пропустил каталог bin только для чтения. –  Marco 17.09.2013, 16:05

Путем я обычно реализую этот вид ограничений, требует, чтобы несколько условий соблюдали, иначе ограничение может легко обойтись:

  • Пользователь не принадлежит wheel группа, единственная, разрешенная использовать su (осуществленный через PAM).
  • Пользователю дают правильно защищенному rbash с ПУТЕМ только для чтения, указывающим на частное ~/bin, это ~/bin/ каталог содержит ссылки на простые утилиты:

    $ 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*
    
  • пользователю дают, ограниченная, среда только для чтения (думайте о материале как LESSSECURE, TMOUT, HISTFILE переменные).

  • пользователь отображается на пользователе SELinux staff_u и, учитывая права выполнить команды как другого пользователя как требуется через sudo.
  • пользователь /home, /tmp и возможно /var/tmp через полиинстанцируют /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
    

    Кроме того, /etc/security/namespace.init делает все скелетные файлы только для чтения для пользователя и принадлежавшими root.

Таким образом, можно выбрать ли $USER может выполниться mkdir от его собственного имени (по ссылке в частном ~/bin каталог, настроенный через /etc/skel, как объяснено выше), от имени другого пользователя (через sudo) или ни один вообще.

15
27.01.2020, 19:39

Добавьте фиктивную группу, добавьте пользователя к той группе, chown root:somegroup /bin/mkdir, chmod g-x /bin/mkdir. Обратите внимание, что это полагается на пользователя, не бывшего способного изменить их группы. IIRC это верно в GNU/Linux, но не в некоторых других Нельдах.

4
27.01.2020, 19:39
  • 1
    В большинстве файловых систем можно также использовать расширенный ACLs для более прекрасного гранулярного управления - количество необходимых групп выросло бы экспоненциально с числом пользователей (из-за возможных комбинаций), не говоря уже о проблемах именования. –  peterph 17.09.2013, 10:19
  • 2
    добавляет еще одну точку, также удаляет разрешение чтения от других пользователей 710, таким образом, пользователь не мог скопировать и переименовать тот двоичный файл не так ли? –  Rahul Patil 17.09.2013, 10:20
  • 3
    @RahulPatil да, и конечно необходимо ограничить их использование компилятора также. –  peterph 17.09.2013, 10:21

установите sudoers и попытайтесь настроить там чьи пользователи и что команда.

-1
27.01.2020, 19:39
  • 1
    Добро пожаловать в SX. Добавьте детали к своему ответу; OP или кто-либо еще читающий этот вопрос в будущем, не может знать sudo. –  Joseph R. 18.09.2013, 15:21
  • 2
    Этот ответ является просто явно неправильным –  kiltek 08.03.2018, 11:26

Лучшее, что я тестировал, это использовать 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/ это местоположение содержит файлы для завершения bash

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

Добавить ниже строки под файлами, эти строки будут блокировать упомянутые команды для нижепольных пользователей

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

save and quit

Now Exit and relogin

С уважением, -Mansur

1
28.07.2021, 14:21

Теги

Похожие вопросы