AppArmor снижает производительность системы?

AppArmor снижает производительность системы? У меня медленная система (процессор с частотой 900 МГц), которая имеет AppArmor, потому что она была установлена по умолчанию. Я хотел бы знать, станет ли она быстрее, если я ее удалю, безопасность менее важна, чем производительность в этой системе.

linux apparmor Petr
источник

Вероятно, не так много, как какой-то угнанный процесс, выполняющий эквивалентrm -rf --no-preserve-root /

jackweirdy

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

Петр

Мой пример был немного преувеличен, хотя в принципе правдоподобен. Отсутствие доступа к Интернету - это другое дело, но рассмотрим большинство современных беспроводных маршрутизаторов, управляемых коммутаторов и систем SCADA - большинство используют веб-интерфейсы для создания отчетов и / или настройки. Некоторые даже позволяют аутентифицированным пользователям изменять файлы конфигурации или запускать команды. Представьте, что в таких интерфейсах были обнаружены слабые места, которые позволяли пользователям, не прошедшим проверку подлинности, запускать команды (вероятно, с правами root, поскольку встроенные устройства часто имеют только одного пользователя). Вы хотели бы, чтобы какой-то механизм гарантировал, что важные элементы (например, / bin) не удалены.

Jackweirdy

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

Jackweirdy

Ответы:

Конечно, это замедляет вашу систему. В какой степени зависит от того, что делают ваши приложения. Доступ к файловой системе медленнее (потому что они должны быть проверены) и все другие вещи, которые можно настроить. Но если процесс не открывает файлы или сокеты и т. Д., Это не должно быть затронуто вообще (после инициализации).

Я только что кратко посмотрел на мою любимую поисковую систему (почему не так?), И в результате это влияние не имеет значения в большинстве случаев.

Хауке Лагинг
источник

Я сам гуглил, я нашел кучу ссылок, говорящих, что это не влияет на это, и кучу ссылок, говорящих об обратном. Пока нет четкого ответа ...

Петр

Кстати, когда я гуглю это сейчас, в основном это просто ссылка на этот самый вопрос, не знаю, что вы нашли, но я не могу найти четкого ответа

Петр

@Petr Конечно, это не независимое измерение, но в документации Novell говорится: «AppArmor не оказывает заметного влияния на производительность». novell.com/documentation/opensuse103/opensuse103_reference/…

Hauke Laging

Хорошо, это стоит отключить или нет?

Петр

Кажется, нет смысла отключать AppArmor по соображениям производительности.

Хауке Лагинг

Если не указано иное, вероятно, следует предположить, что «никакого заметного эффекта» предполагается процессор 1,8 ГГц + и около 512 МБ памяти или более. Одна из моих машин - 800 МГц, 512 МБ памяти. Эффект каждого процесса заметен. Только вы можете судить, стоит ли это того.

DocSalvager
источник

Это зависит от того, что делает ваша программа: как часто она обращается к файлам, как часто она запускает новые программы, как долго она запускается, ... AppArmor строится с использованием [LSM] 1интерфейс, который проверяет каждый системный вызов. AppArmor может иметь кэш доступа для ускорения повторяющихся обращений к файлу или последующих запросов к уже открытому файлу из того же процесса, но наиболее заметные накладные расходы возникают во время инициализации (должен быть загружен профиль программы и должна выполняться некоторая инициализация контекста). ). Если вы настроены на какое-то непрактичное суждение о наихудших случаях, ниже приведен рисунок, сравнивающий AppArmor с DAC (традиционная модель разрешений) во время исследования какой-то другой платформы на основе LSM (CMCAP-Linux). Система представляла собой Linux 4.4.6, загруженную на Intel Core2 Duo E8400 с тактовой частотой 3 ГГц и 8 ГБ ОЗУ. Микропроцессорный тест состоял из 10 усредненных прогонов (в тесных циклах) из 10 миллионов операций для теста open + close и 10 тысяч для двух других.

Butshuti
источник