Можно ли запретить любому пользователю использовать такие команды, как ls, rm и другие системные команды, которые могут нанести вред системе. Но пользователи должны иметь возможность запускать программы оболочки.
Ваш вопрос должен быть таким:
Я не доверяю своим пользователям. Глупые видят что-то в Интернете и пробуют, не понимая, что это делает. Коварные люди любят шпионить и просматривать файлы других людей и красть их идеи. И ленивые, не заставляйте меня начинать с ленивых.
Как мне защитить мою систему и моих пользователей от моих пользователей?
Во-первых, unix имеет очень всеобъемлющую систему разрешений для файловой системы. Кажется, это достойный учебник по разрешениям файловой системы unix.. Суть этого в том, что каталоги могут быть настроены таким образом, чтобы пользователь мог заходить в каталог и запускать программы из этого каталога, но не мог просматривать содержимое этого каталога. Если вы сделаете это, например, в / home, если пользователь запустит ls в / home, он получит ошибку «Доступ запрещен».
Если вы действительно боитесь своих пользователей и хотите засунуть их в сверхмакс Тип ограниченного окружения, используйте что-то вроде тюрьмы freebsd или зон solaris - каждый пользователь получает свою индивидуальную среду. Для добавленных точек используйте ZFS, чтобы вы могли сделать снимок среды при входе в систему, поэтому, если они удалят свои файлы, вы можете просто вытащить их из снимка.
Чтобы полностью выполнить то, о чем вы просите, необходимо выполнить три вещи:
Пояс, подтяжки и степлер на всякий случай. Тут сложно ошибиться.
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.
На мой взгляд, вам нужны только шаги 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 переменные).
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?