Предотвращение просмотра моих файлов другими пользователями [закрыто]
Хорошо, теперь я понимаю, о чем идет речь
Cmnd_Alias CMDS = / usr / sbin / userdel * sysadmin, ... % admin ALL = (ALL) ALL,! SHELLS,! SU, ! CMDS,! PASS,! EDIT
к сожалению, это ужасная идея.
В области безопасности общий принцип заключается в том, что вы должны быть в состоянии описать, что вы разрешаете . На удивление редко удается составить список того, что не разрешено, и быть уверенным, что вы ничего не пропустили.
В частности,
$ cp /usr/sbin/userdel ./letsbefriends
$ sudo ./letsbefriends sysadmin
(и тот же принцип применяется к конфигурации, которая конкретно блокирует sudo su / sudo sudo ).
В качестве положительного примера рассмотрим этот список разрешенных задач для вашего пользователя «admin» [*]:
# admin can run `reboot`. (They can't run e.g. `reboot --force`).
admin ALL=(ALL) reboot ""
Почему [is] «user-3121» отсутствует в / etc / sudoers?
Отличный вопрос! Пользователь-3121 является членом группы sudo . В / etc / sudoers этой группе соответствует строка % sudo .
Вы можете подумать: «Ты показал мне симпатичный прием. Конечно, я мог бы придумать способ заблокировать и его». И есть подходы, которые вы можете использовать. Но вы бы спорили ради этого и пытались не принимать общий принцип.
Кто-то другой приходит с другой идеей. Что это значит? [**]
$ sudo /proc/self/exe sh
Это два разных примера, которые вам нужно будет настроить для блокировки вашей системы. Вы можете поверить, что я знаю больше. Вы в конечном итоге пишете эту сложную настраиваемую конфигурацию. Сложные системы неизбежно содержат ошибки.Вы хотели создать собственную систему, устранять неполадки и поддерживать ее? Обычно вы хотите попробовать работать с установленной вами операционной системой, чтобы получить выгоду от всей работы, которая идет на ее разработку, документирование и поддержку.
[*] На практике ограничение sudo определенными целями бывает сложнее, чем можно было бы нравиться. Я полагаю, что не принято полагаться на правила sudo, чтобы обеспечить настоящий барьер безопасности. Вместо этого он используется для делегирования полномочий на выполнение определенных задач, защищая пользователей от самих себя. Это снижает вероятность ошибки и записи нулей по всему их ценному жесткому диску или прошивке на сетевой карте.
[**] Спойлер:
sudo / proc / self / exe sh запускает оболочку от имени пользователя root.
Он обходит черный список, определенный как SU , используя ту же технику выполнения команды (sudo) с использованием альтернативного имени файла, которого нет в черном списке. Итак, этот второй экземпляр sudo успешно запущен от имени пользователя root . Опубликованная конфигурация позволяет пользователю root запускать любую команду через sudo . Таким образом, второму экземпляру sudo разрешено запускать оболочку от имени пользователя root.
Полученную оболочку можно использовать для запуска любой команды от имени root . Оболочка не использует sudo, поэтому она не просматривает списки заблокированных команд в sudoers . Например. оболочка могла запустить su для входа в оболочку, работающую от имени любого данного пользователя, не зная его пароля.
Итак, подведем итоги чата для всех, у кого возник этот вопрос. В основном он изменил права доступа к своей домашней директории на 0700 (только он может читать писать выполнять)
chmod 0700 /homedirectory
Затем остальная часть чата была попыткой убедиться, что админ не может su его или sudo su его. (Да, он мог бы получить файлы другими способами, но у него нет прав). Это влечет за собой изменение прав доступа в /etc/sudoers и убедитесь, что только root имеет права на редактирование /etc/sudoers.
Легко, если это учетная запись типа «администратор», то вы должны предполагать, что она может делать что угодно. (Пример приведен ниже)
(Также, если у пользователя есть доступ к меню загрузчика или интерфейсу конфигурации микропрограмм, также известному как экран настройки BIOS).
Если вы можете запускать команды по вашему выбору под идентификатором пользователя 0 (например, sudo), то у вас, по сути, тот же уровень доступа, что и у процесса, который изначально установил вашу операционную систему. Или в качестве одного из аварийных дисков , с которого вы можете загрузиться - они могут создавать резервные копии всех ваших файлов или переносить их с одного диска на другой для целей обновления и т. Д.
Без определенного программного обеспечения TPM (которое не реализовано в Ubuntu или аналогичном) они могли бы установить кейлоггер для захвата вашего пароля или отключения любых проверок аутентификации, которые вы внедряете.
Индивидуальное шифрование может предотвратить случайный доступ. Документация сообщества Ubuntu, последний раз обновлявшаяся два года назад, утверждает, что вы можете включить это: https://help.ubuntu.com/community/EncryptedHome
Пример доступа к файлу
По-видимому, некоторые пользователи думают, например, chmod 0700 защищает ваши каталоги. Это неверно. Вы можете придумать ситуации, в которых это сработает, но одного этого недостаточно. Пример работы на Fedora Workstation 24, ext4 filesysem:
$ mkdir secret # directory with "secret" contents
$ chmod 0700 secret # apply access control
$ ls -ld secret # show access control
drwx------. 2 alan-sysop alan-sysop 4096 Nov 13 20:31 secret
$ sudo -u nobody ls -l secret # other user ("nobody") is denied access
[sudo] password for alan-sysop:
ls: cannot access 'test': Permission denied
$ sudo ls -l secret # but root user bypasses access controls (CAP_DAC_OVERRIDE)
total 0