Могу ли я создать суперпользователя * super *, чтобы у меня действительно был пользователь, который может лишить права root?

Я думал, что было бы выгодно иметь пользователя с правами доступа, превышающими пользователя root.

Вы видите, что я хотел бы сохранить все действия и почти все существующие привилегии пользователя root точно так, как они есть сейчас.

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

Одно из преимуществ этого позволит мне предотвратить установку некоторых нежелательных файлов во время обновлений. Это просто пример одного из возможных преимуществ.

Поскольку обновления apt-get запускаются с помощью root или с привилегиями sudo, apt-get имеет возможность заменять некоторые нежелательные файлы во время обновлений.

Если бы я мог отрицать эти привилегии для этих отдельных конкретных файлов, я мог бы установить их как ссылку на /dev/null или, возможно, иметь пробел файл-заполнитель, который может иметь разрешения, запрещающие замену файла во время обновления.

Кроме того, я не могу не напомнить о строке, о которой говорилось в интервью одному из создателей Ubuntu, когда парень сказал что-то о том, как пользователи лучше доверяют «нам» (ссылаясь на разработчиков Ubuntu) », потому что у нас есть корень ", который был ссылкой на то, как системные обновления выполняются с правами root.

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

Я только подумал об этом и до сих пор не потратил времени на эту идею, и я уверен, что это можно понять. Тем не менее, мне любопытно узнать, было ли это уже сделано или это возможно не новая идея или концепция.

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


Примечание. Хотя я считаю, что принятый ответ наиболее соответствует критериям, мне очень нравится ответ @CR. также.

Я хотел бы создать фактического пользователя выше на дереве (мне), но я думаю, мне просто нужно сесть однажды, когда у меня будет время выяснить это.

Кроме того, я не пытаюсь выбрать Ubuntu здесь; Я бы не использовал его в качестве основного дистрибутива, если бы чувствовал себя отрицательно.

33 голоса | спросил mchid 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 04 Sep 2017 00:06:31 +0300 2017, 00:06:31

3 ответа


8

Для программного обеспечения, такого как APT , который при нормальной работе требует доступа практически ко всей системе, ограничение является проблематичным. Даже если вы не позволите ему получить доступ к определенным частям системы, скорее всего, более чем достаточно возможностей для вредоносного дистрибьютора для работы. Например, заменив библиотеку или просто бинарный файл или добавив вредоносное изменение конфигурации, которое в конечном итоге будет использовать неограниченный корень.

В зависимости от того, сколько вы разместили ограничения, можно ожидать, что некоторые скрипты установки могут сломаться.

Для способов ограничения приложений и пользователей вы можете написать политику AppArmor или SELinux. Такая политика будет больше поддерживаться в зависимости от вашего дистрибутива: на основе Debian лучше поддерживать AppArmor, тогда как дистрибутивы на основе Fedora /RHEL по умолчанию включают SELinux.

Оба AppArmor и SELinux работают над политиками white list , которые содержат правила, позволяющие разрешать (или запрещать) конкретные действия. Политики применяются к процессу в exec , аналогичным образом пользователи могут быть ограничены, когда политика применяется к их процессам при входе в систему. Хорошо продуманная политика не может быть обойдена (если ошибки ядра не рассматриваются). Конфиденциальный процесс, выполняемый с правами root (uid 0), ограничен установленной политикой и не может изменить его, если явно не разрешено в политике.

Язык политики AppArmor определяет правило запрещения . , который можно использовать для создания политики . Хорошим местом для начала AppArmor является AppArmor справочные страницы , wiki и посмотрев существующую конфигурацию вашего дистрибутива в /etc/apparmor.d/.

Множество материалов администрирования и разработки SELinux представлено в викинге SELinux . SELinux справочная политика размещается на github.

ответил sebasth 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 04 Sep 2017 00:34:29 +0300 2017, 00:34:29
1

Поместите резервную копию в безопасное место. После любой установки /обновления немедленно замените определенные файлы из резервной копии. Таким образом, нет ошибок, чтобы испортить установку, но вы все равно возвращаете файлы, которые вы хотели сохранить.

ответил WGroleau 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 04 Sep 2017 10:41:39 +0300 2017, 10:41:39
0

UNINSTALL sudo

Как насчет удаления sudo и symlink /bin/su to /bin/false? Соедините это, убедившись, что root не может войти через ssh, и вы заблокировали систему.

Это делает root Super * Super User, и все остальные подчиняются этому.

Для файлов, замененных во время обновлений, просто не делайте никаких обновлений. Более реалистично, измените разрешения файлов на 440 или 444, чтобы они не могли быть написаны. Или поместите их в репозиторий git, так что, если они будут перезаписаны, его можно вернуть.

ответил user176717 7 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 07 Sep 2017 02:25:27 +0300 2017, 02:25:27

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132