Некоторые основные вопросы о безопасности ядра Linux [закрыто]

8

Я не знаю много о ядре Linux, и у меня есть несколько вопросов.

  1. Какова основная цель отделения памяти ядра от памяти пространства пользователя? Чтобы убедиться, что пользовательское приложение не может сделать ничего плохого ядру?

  2. Сколько существует способов для приложения уровня пользователя передать управление ядру? Что я могу придумать: include (1) вызов системного вызова, (2) отображение памяти в ядре (но я думаю, что mmap () также системный вызов) и (3) загрузка модуля ядра (но я думаю, lsmod также вызывает некоторый системный вызов). Я прав? Есть ли другие способы, которые я пропустил?

  3. Сколько способов атаковать ядро? Могу ли я иметь некоторые краткие сведения о них?

  4. Если я получаю привилегию root, значит ли это, что я полностью контролирую ядро? А именно, я могу делать все, что захочу с ядром и оборудованием? Или у меня все еще ограничена мощность ядра?

Я был бы очень признателен, если бы кто-нибудь смог помочь мне найти ответ на эти вопросы.

linux kernel security linux-kernel system-calls hebothu
источник
1
Здесь есть несколько хороших вопросов, но не могли бы вы разделить их на более конкретные вопросы по одной основной теме на вопрос?
Калеб

Ответы:

5

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

  1. Очень желательна изоляция памяти для процессов пользовательского пространства - не только для защиты ядра от вредоносных программ пользовательского пространства, но и для защиты программ пользовательского пространства друг от друга. Обычно это называется виртуальной памятью . Это также облегчает реализацию подкачки страниц, что также желательно по другим причинам (более простая фрагментация, более простые компоновщики / загрузчики и т. Д.).

  2. Прерывания (не все из которых контролируют приложение уровня пользователя). Отказ процессора также отнимает «контроль» у процесса (например, waitи т. Д., Которые также являются системными вызовами). Ядро само может решить отменить планирование приложения.

  3. Это очень широкий вопрос. Ядро с плохо реализованными системными вызовами уязвимо. Возможность записи в физическую память была бы другим способом. Существуют и другие уязвимости, которые могут возникнуть из-за плохо реализованных инструкций (например, уязвимость sysret в процессорах Intel).

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

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

Если кто-то может улучшить некоторые ответы, пожалуйста, не стесняйтесь указывать на это.

mtahmed
источник
Спасибо за ваш ответ. Вы сказали «Прерывания (не все из которых управляют приложением уровня пользователя)». Это означает, что только программные прерывания контролируют уровень пользователя, а аппаратные прерывания - нет. Это правильно?
hebothu
Я считаю, что пользовательское пространство должно как-то попросить пространство ядра разрешить ему обрабатывать некоторые прерывания. Таким образом, ядро ​​в основном все еще контролирует прерывания. В частности, ядро ​​все еще обрабатывает прерывания и передает их в пользовательское пространство, если приложение пользовательского пространства хочет получить его. Поиск Linux UIO.
mtahmed