Вы много просили.
Существует несколько возможных подходов:
Собственные разрешения Linux
Создайте для этого нового пользователя свою новую группу. Сделайте их единственным членом этой группы.
Удалите права на чтение, запись, выполнение для всех ваших файлов данных. Если какие-либо пользователи получали свои права доступа к файлам данных через права доступа world , либо создайте новые группы для всех пользователей и данных соответствующим образом (возможно, одну для accounting, одну для billing, одну для sales, один для engineering и т. Д. Что бы ни работало.)
Добавьте новую запись sudoers(5) для этого пользователя для sudo stop tomcat, sudo start tomcat, sudo restart tomcat, sudo status tomcat - или любых других команд, которые этот пользователь должен будет выполнить для управления службой tomcat. Подробнее о редактировании файла конфигурации sudo(8) см. visudo(8).
Если вы действительно хотите заблокировать этого пользователя, скопируйте утилиты, которые понадобятся этому человеку, в их ~/bin/ директорию, а затем продолжайте удалять бит выполнения мира в /bin, /sbin, /usr/bin, /usr/sbin. (Оставьте /lib, /usr/lib и т. Д. В покое - копирование в библиотеки, которые понадобятся этому пользователю, несомненно, является лотом работы.)
Обязательный контроль доступа
Я объясню это с помощью системы AppArmor ; Я работал над AppArmor более десяти лет, и это система, которую я знаю лучше всего. Есть еще несколько вариантов: TOMOYO , SMACK и SELinux - все это отличные инструменты. AppArmor и TOMOYO работают над идеей, что вы ограничиваете доступ к путям . SMACK и SELinux работают над идеей, что каждому объекту в системе назначается метка, а политика определяет, какие метки (для процессов) могут читать, записывать, выполнять и т. Д. Метки (для данных или других процессов). Если вы хотите обеспечить всеобъемлющий открытый, секретный, секретный, сверхсекретный стиль защиты, лучше использовать SMACK или SELinux. Если вы хотите ограничить некоторые программы некоторыми файлами, лучше использовать AppArmor или TOMOYO.
AppArmor должен быть готовым к использованию в большинстве дистрибутивов Ubuntu, SUSE, PLD, Annvix, Mandriva и Pardus.
Система AppArmor ограничивает процессы и контролирует, как процессы могут перемещаться из домена в домен, когда процессы выполняют новые программы. Домены обычно назначаются программой .
Самый простой способ начать работу - скопировать /bin/bash в /bin/jail_bash (или другое имя , а не в /etc/shells), установить оболочку для пользователя в /etc/passwd (chsh(1) может сделать это легко), и создайте профиль AppArmor для /bin/jail_bash, который разрешает только те действия, которые вы хотите разрешить. Если мы правильно ограничим процесс, пользователь не сможет выйти из профиля, который мы для него создали.
Добавьте новую запись sudoers(5) для этого пользователя для sudo stop tomcat, sudo start tomcat, sudo restart tomcat, sudo status tomcat - или любых других команд, которые этот пользователь должен будет выполнить для управления службой tomcat. Подробнее о редактировании файла конфигурации sudo(8) см. visudo(8).
В одном терминале запустите aa-genprof jail_bash. В другом терминале войдите в систему как пользователь (или иначе запустите /bin/jail_bash) и начните выполнять задачи, которые вы хотите разрешить этому человеку. Мы будем использовать то, что вы делаете в качестве учебного материала, для многократного построения профиля. Возможно, вам будет интересно посмотреть /var/log/syslog или /var/log/audit/audit.log (если у вас установлен пакет auditd), чтобы увидеть, какие операции AppArmor замечает в вашей программе. Не делайте слишком много сразу - только несколько новых вещей за итерацию.
В терминале aa-genprof ответьте на вопросы по мере их появления. Разрешить то, что должно быть разрешено. Отрицать то, что должно быть отказано. Когда вас спросят о привилегиях выполнения , предпочтите наследовать или потомок вместо профиль . (Опция profile будет влиять на всех остальных в системе. Inherit или child будет влиять только на выполнение из профиля, над которым вы сейчас работаете над улучшением. Дочерний разбивает привилегии на более мелкие части, в то время как наследует сохраняет разрешения в более крупных профилях. Для этого случая предпочитают наследовать .)
Как только вы получите вопросы о выполнении tomcat, используйте привилегию неограниченное выполнение . Это опасно - если ошибка в том, как запускается tomcat, позволяет людям запускать неограниченные оболочки, то это можно использовать для выхода из тюрьмы. Вы могли бы ограничить tomcat (и это даже хорошая идея - tomcat не идеален), чтобы не допустить, чтобы это стало маршрутом побега, но это, вероятно, не является необходимым сразу.
AppArmor разработан, чтобы упростить расширение профилей в системе с течением времени. AppArmor не применим к всем ситуациям безопасности, но мы развернули сценарии, очень похожие на это, на DEF CON конкурсе хакерских захватов с отличными результатами, Нам пришлось разрешить злоумышленникам root (и эфемерным учетным записям пользователей) доступ к машине через telnet, а также POP3, SMTP, HTTP + CGI и FTP.
Обязательно проверяйте вручную профили в /etc/apparmor.d/, прежде чем позволить своему пользователю войти в систему. Вы можете исправить все, что захотите, с помощью простого текстового редактора; запустите /etc/init.d/apparmor restart, чтобы перезагрузить все профили (и выгрузить профили, которые вы можете удалить).
Удобно держать открытую оболочку root sash(1) открытой, когда вы впервые изучаете, как настроить AppArmor. Если вы игнорируете предупреждение о программах, которые не должны иметь свой собственный профиль, может быть трудно вернуться в вашу собственную систему. (Не забудьте о загрузке с init=/bin/sh в худшем случае.)