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

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

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

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

Во-первых, 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 в каталог, где хранятся все разрешенные двоичные файлы / скрипты.

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

• Пользователь не принадлежит 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) или нет вообще.

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

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

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

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

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

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

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

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