Как ограничить пользовательскую оболочку, позволяющую запускать программы оболочки

Можно ли запретить любому пользователю не использовать такие команды, как ls, rm и другие системные команды, которые могут нанести вред системе. Но пользователи должны иметь возможность выполнять программы оболочки.

Ваш вопрос должен быть:

Я не доверяю своим пользователям. Глупые видят что-то в интернете и пробуют, не понимая, что это делает. Лукавым нравится обнюхивать, смотреть на файлы других людей и красть их идеи. И ленивый, не заводите меня на ленивых.

Как защитить мою систему и моих пользователей от моих пользователей?

Во-первых, Unix имеет очень полную систему разрешений файловой системы. Это хороший учебник по разрешениям файловой системы unix . Суть этого в том, что каталоги могут быть установлены таким образом, чтобы пользователь мог войти в каталог и мог запускать программы из этого каталога, но не мог просматривать содержимое этого каталога. Если вы сделаете это, например, в / home, если пользователь запустит ls в / home, он получит ошибку отказа в разрешении.

Если вы действительно боятся пользователей и хотите вставить их в Supermax типа ограниченной среды, использовать что - то вроде тюрьмы в FreeBSD или зон для Solaris - каждый пользователь получает свой собственный портной сделал среду. Для добавленных точек используйте ZFS, чтобы при входе в систему вы могли сделать снимок среды, и если они удаляют свои файлы, вы можете просто извлечь их из снимка.

Есть три вещи, которые должны быть в наличии, чтобы полностью выполнить то, что вы просите:

1. Пользовательская оболочка, в которой отсутствуют нужные вам команды . Это трудно получить, но если вы действительно не хотите, чтобы пользователи имели доступ к некоторым примитивам оболочки, это единственный способ удалить их.
2. Правильно установите права доступа к файлу . Не хотите, чтобы пользователи повредили систему? Установите разрешения, чтобы они не могли повредить систему, даже если у них есть нужные инструменты. Из этих трех шагов это самый простой шаг.
3. Используйте обязательный контроль доступа технолой, как AppArmor . MAC, такие как AppArmor и SELinux, встраивают разрешения в ядро. Они не позволяют пользователям запускать нужные инструменты, даже если они их где-то находят (и, как и права доступа к файлам, не позволяют им использовать их за пределами поля с ограничениями).

Пояс, подтяжки и скобы для хорошей меры. Трудно ошибиться там.

AppArmor интересен тем, что MAC для конкретного исполняемого файла наследуется всеми его дочерними элементами. Установите имя пользователя для входа в систему /bin/bash-bob, установите профиль AppArmor для этого конкретного бинарного права, и единственный способ, которым он выходит из этой тюрьмы разрешений, - через эксплойты ядра. Если какой-то ленивый установочный скрипт остался /var/opt/vendor/tmpглобально доступным для записи по какой-то глупой причине, пользователь, использующий в /bin/bash-bobкачестве оболочки , не сможет писать туда . Настройте профиль bash-bob так, чтобы разрешить запись только в его домашнюю директорию /tmp, и такие ошибки не могут быть использованы. Даже если они каким-то образом найдут пароль root, профиль AppArmor по- /bin/bash-bobпрежнему будет применяться даже после того, как suон с тех пор, suи bashпроцесс, который он порождает, является дочерним /bin/bash-bob.

Сложная часть - это создание профиля AppArmor.

1. Создайте профиль AppArmor для / bin / bash-bob и установите его в режим аудита
2. Установите логин-оболочку Боба в / bin / bash-bob
3. Войдите как Боб. Делай все, что хочешь, чтобы Боб мог делать.
4. Используйте Auditlog для создания профиля AppArmor (SUSE имеет инструменты для этого, не уверенный в других дистрибутивах Linux). Это чудовищно утомительно, но должно произойти, если вам нужен этот уровень безопасности.
   1. Вы будете делать такие вещи, как:
      • Утверждение доступа для чтения к большинству системных библиотек
      • Утверждение прав на чтение и выполнение выбранных нескольких разрешенных системных команд
      • Утверждение доступа на запись во временные пространства
      • Утверждение создания сокета, если необходимо
5. Установите политику для обеспечения соблюдения.
6. Войдите как Боб, делайте вещи.
7. Внести коррективы.

На мой взгляд, вам нужны только шаги 2 и 3, поскольку в сочетании они оба препятствуют возможности делать что-либо вредное за пределами тщательно сконструированной коробки, которую вы установили на обоих этих шагах.

Ну, вы можете установить оболочку пользователя для программы, которую вы написали, которая позволяет им запускать только определенные сценарии оболочки.

Конечно, это будет так же безопасно, как программа и сценарии оболочки; на практике этот тип ограниченной оболочки обычно не защищен от умного злоумышленника.

Не пытайтесь ограничивать команды, ограничивайте права доступа к файлам. Вы не можете практически ограничить доступ людей к системным вызовам, поэтому все, что нужно сделать, это предоставить свою собственную копию любых «опасных» команд, которые вы не хотите, чтобы они выполняли, и вы забиты.

Если вы хотите, чтобы пользователь мог выполнять только определенные сценарии / двоичные файлы, вы можете использовать ограниченную оболочку . Это (как упоминается в статье в Википедии) не является полностью безопасным, но если вы можете гарантировать, что ни одно приложение, которое может быть запущено, не сможет выполнить новую оболочку, то это хорошая альтернатива.

Чтобы настроить оболочку с ограниченным доступом пользователей, установите /bin/rbash(или аналогично, большинство оболочек переходят в режим с ограниченным доступом, когда двоичный файл называется r *** name *) в качестве оболочки пользователя. Затем отредактируйте **. Bashrc (или эквивалентный) и установите $PATHкаталог, в котором хранятся все разрешенные двоичные файлы / сценарии.

Да, это возможно, но на практике это потребует много работы и планирования. Вы можете создавать сценарии и запускать их как привилегированное использование, а затем удалять все привилегии у данного пользователя. Или вы можете настроить оболочку пользователя на что-то свое, что позволит ему делать только то, что вы явно разрешаете.

Однако стандартные разрешения в linux делают практически невозможным для обычного пользователя «навредить системе». Какой вред вы пытаетесь предотвратить? Это тривиально, чтобы пользователи не могли устанавливать программное обеспечение или запускать программы вне своего домашнего каталога, и вы можете использовать chroot для еще большей блокировки системы.

Вы можете попробовать [lshell] [1] (ограниченная оболочка).

lshell - это оболочка, написанная на Python, которая позволяет ограничить среду пользователя ограниченным набором команд, выбрать включение / отключение любой команды через SSH (например, SCP, SFTP, rsync и т. д.), регистрировать команды пользователя, реализовывать ограничение по времени, и более.

[1]: http://lshell.ghantoos.org/Overview lshell

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

• Пользователь не принадлежит к wheelгруппе, единственный, кому разрешено использовать su(принудительно применяется через PAM).

• Пользователю предоставляется надлежащая защита rbash с доступом только PATHдля чтения к частному ~/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выполнять ли какую-либо команду от своего собственного имени (через ссылку в личном ~/binкаталоге, предоставленную через /etc/skel, как описано выше), от имени другого пользователя (через sudo) или вообще без нее .

Да, просто измените разрешения для этих команд.

У вас может быть больше шансов на сражение, написав команду оболочки, которая ведет себя в соответствии с вашими требованиями.

Что не подходит по умолчанию разрешения для обычных пользователей в Linux?