Як обмежити оболонку користувачів, дозволяючи виконувати програми оболонок

Чи можна заборонити будь-якому користувачеві використовувати такі команди, як ls, rm та інші системні команди, які можуть завдати шкоди системі. Але користувачі повинні мати можливість виконувати програми оболонки.

Ваше питання має бути:

Я не довіряю своїм користувачам. Німі бачать щось в Інтернеті і спробують це, не розуміючи, що це робить. Нерозумні люблять лунати навколо та дивитись файли інших народів і красти їхні ідеї. І ледачі, не запускайте мене на ледачих.

Як захистити свою систему та своїх користувачів від своїх користувачів?

По-перше, unix має дуже всеосяжну систему дозволів файлової системи. Це здається гідним підручником щодо дозволів файлової системи Unix . Суть у тому, що каталоги можуть бути встановлені таким чином, що користувач може зайти в каталог і може запускати програми з цього каталогу, але не може переглядати вміст цього каталогу. Якщо ви робите це, наприклад, у / home, якщо користувач працює ls on / home, вони отримують помилку, у якій відмовлено у дозволі.

Якщо ви дійсно боїтесь своїх користувачів і хочете вставити їх у супермакс- тип обмеженого середовища, використовуйте щось на кшталт в'язниць 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, і такі помилки дозволу не можна використовувати. Навіть якщо вони якимось чином знайдуть корінь пароля, профіль AppArmor /bin/bash-bobвсе одно буде застосовуватися навіть після того, як вони suз'явилися з тих пір, suі bashпроцес, який він породжує, є дітьми /bin/bash-bob.

Важкою частиною є створення цього профілю AppArmor.

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

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

Ну, ви можете встановити оболонку користувача на програму, яку ви написали, яка дозволяє лише виконувати певні сценарії оболонки.

Звичайно, це було б так само безпечно, як сценарії програми та оболонки; на практиці цей тип обмеженої оболонки зазвичай не захищений від розумного нападника.

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

Якщо ви хочете, щоб користувач міг виконувати лише певні сценарії / бінарні файли, ви можете використовувати обмежений оболонку . Це (як згадується у статті Вікіпедії) не є повністю безпечним, але якщо ви можете гарантувати, що жодна програма, дозволена до запуску, не зможе виконати нову оболонку, то це хороша альтернатива.

Щоб налаштувати оболонку з обмеженим користувачем, встановіть /bin/rbash(або подібне, більшість оболонок переходять у обмежений режим, коли двійковий називається r *** ім'я *) як оболонка користувачів. Потім відредагуйте **. 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?