Разработка системы на основе Linux для передачи прав собственности / прав администратора без полного доверия - PullRequest
2 голосов
/ 09 июля 2009

Вдохновленный гораздо более конкретным вопросом о ServerFault.

Мы все должны доверять огромному количеству людей в отношении безопасности и целостности систем, которые мы используем каждый день. Здесь я имею в виду всех авторов всего кода, работающего на вашем сервере или ПК, и всех, кто занимается проектированием и сборкой аппаратного обеспечения. Это смягчается репутацией и, где источник доступен, рецензирование.

Кто-то, кому вы, возможно, придется доверять, упоминается гораздо реже, это человек, который ранее имел root-права в системе. Ваш предшественник как системный администратор на работе. Или для домашних пользователей, тот хороший знакомый с Linux друг, который настроил вашу систему для вас. Предыдущий владелец вашего телефона (вы действительно можете доверять кнопке Factory Reset?)

Вы должны доверять им, потому что есть очень много способов сохранить root , несмотря на все усилия нового администратора, и это только те, о которых я мог подумать в течение нескольких минут. Любой, кто когда-либо имел root в системе, мог оставить все виды сумасшедших бэкдоров, и единственным реальным выходом из любой системы на базе Linux, которую я видел, является переустановка вашей ОС и всего кода, который когда-либо мог работать с любыми привилегиями. , Скажем, смонтировать /home с noexec и переустановить все остальное. Даже этого недостаточно, если любой пользователь, чьи данные остаются, может когда-либо получить привилегию или повлиять на привилегированного пользователя достаточно подробно (например, псевдонимы оболочки и другие вредоносные конфигурации). Постоянство привилегий не новая проблема .

Как бы вы спроектировали систему на основе Linux, в которой наивысший уровень привилегированного доступа может быть гарантированно отменен без полной переустановки? Или какая такая система уже существует? В качестве альтернативы, почему создание такой системы логически невозможно?

Когда я говорю «на основе Linux», я имею в виду нечто такое, что может запускать столько программного обеспечения, которое работает на Linux сегодня, насколько это возможно, и как можно меньше модификаций этого программного обеспечения. Физический доступ традиционно означал, что игра закончена из-за таких вещей, как клавиатурные шпионы, которые могут передавать, но предположим, что оборудование достаточно инспектируемо / очевидно, чтобы сделать непрерывный доступ по этому маршруту достаточно трудным, просто потому, что я (и пользователи SO?) Нахожу Программные аспекты этой проблемы интереснее. :-) Вы также можете предположить, что существует BIOS, который может быть перезагружен известным образом или не может быть перепрошит вообще.

Мне известны самые основы SELinux, и я не думаю, что это сильно поможет, но я никогда им не пользовался: не стесняйтесь объяснять, как я неправ.

Ответы [ 2 ]

1 голос
/ 09 июля 2009

Прежде всего, вы сказали design :) Мой ответ будет содержать ссылки на материалы, которые вы можете использовать прямо сейчас, но некоторые из них еще недостаточно стабильны для производства. Мой ответ также будет содержать ссылки на то, что нужно написать.

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

Я был очень активен в новой файловой системе несколько лет назад, которая называлась ext3cow , копия на запись версии ext3. Снимки были дешевыми и на 100% неизменными, порт с Linux 2.4 до 2.6 сломался и в прошлом отказывался от возможности изменять или удалять файлы.

Фунт за фунт, это было так же эффективно, как ext3. Конечно, ничего особенного в этом нет, но это (и по большей части) все еще является стандартом производства FS.

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

На этом этапе, пройдя через diff, вы можете решить, что ничего интересного нет, и просто изменить пароль root, или же вы можете проверить вещи, которые кажутся немного странными.

Теперь о том, что нужно написать, если будет найдено что-то интересное:

  • Что-то, что вы можете передать через diff, хотя и исследует каждый файл. То, что вы увидите, - это список ревизий на файл, и в это время их придется рекурсивно сравнивать. То есть представить против прежнего настоящего, бывшего настоящего против прошлого1, прошлого1 против прошлого2 и т. д., пока не дойдете до исходного файла или до точки, что его больше не существует. Делать это вручную серьезно отстой. Кроме того, для начала вам необходимо определить файлы, которые никогда не были версионированы.
  • Что-то, чтобы проверить ваше текущее работающее ядро. Если кто-то испортил VFS, ничего из этого не получится, файловые системы CoW используют временные inode для доступа к файлам в прошлом. Я знаю многих корпоративных клиентов, которые немного модифицируют ядро, вплоть до модулей, включая VMM и VFS. Это может быть не такой простой задачей - сравнение с «нетронутым» может оказаться недопустимым, поскольку старый администратор, возможно, сделал хороших изменений в ядре с момента его установки.
  • Базы данных представляют собой особую головную боль, поскольку они обычно меняются каждую секунду или более, включая таблицу пользователей. Это нужно будет проверять вручную, если только вы не найдете что-то, что может проверить, чтобы убедиться, что ничего странного, такой инструмент будет очень специфичным для вашей установки. Классический корень UNIX здесь не единственная ваша задача.

Теперь рассмотрим другие компьютеры в сети. Сколько из них работает под управлением ОС, которая, как известно, легко эксплуатируется и заражена ботами? Даже если ваш сервер чист, что если этот парень присоединится к #foo на irc и начнет атаку на ваши серверы через вашу собственную локальную сеть? Большинство людей нажимают на ссылки, которые присылает сотрудник, особенно если это сочная запись в блоге о компании. Социальная инженерия очень проста, если вы делаете это изнутри.

Короче говоря, то, что вы предлагаете, является правдоподобным, однако я сомневаюсь, что большинство компаний могли бы применять лучшие практики, необходимые для его работы при необходимости. Если в результате вы обнаружите BOFH в своей рабочей силе и нуждаетесь в нем, вам лучше будет содержать его на протяжении всей его работы.

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

Edit:

Да, я знаю о виртуальных машинах и контрольных точках, предполагающем решение, которое выводит на новый уровень рекурсии. Имел ли (ныне ушедший) администратор прямой root-доступ к привилегированному домену или серверу хранения? Возможно, да, именно поэтому я не рассматриваю это для целей этого вопроса.

1 голос
/ 09 июля 2009

Посмотрите на Доверенные вычисления . Основная идея заключается в том, что BIOS загружает загрузчик, затем хэширует его и отправляет этот хэш на специальный чип . Затем загрузчик хэширует ядро ​​ОС, которое, в свою очередь, хэширует все драйверы режима ядра. Затем вы можете спросить у чипа , были ли все хэши как ожидалось.

Предполагая, что вы доверяете человеку, который первоначально установил и настроил систему, это позволит вам доказать, что ни у одной из последующих системных администраторов в вашей ОС не было руткита. Затем вы можете вручную запустить хеш для всех файлов в системе (поскольку руткита нет, значения будут точными) и сравнить их со списком, предоставленным исходным установщиком. Любые измененные файлы должны быть тщательно проверены (например, / etc / passwd будет изменен из-за законного добавления новых пользователей).

Я понятия не имею, как бы вы справились с исправлением такой системы, не нарушив цепочку доверия.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...