Comments 26
полезно. Немногие знают про этот замечательный инструмент, шикарно помогает при отладке странных глюков в приложениях, особенно когда одного debug-лога не хватает
Я им пользуюсь, чтобы проверить работу вебсервера, когда непонятно, почему при внешне правильном конфиге он выдаёт, например, 404 ошибку.
Ха, я настолько суров, что читаю RSS через strace.
Запускаю ридер, подключаю к нему strace и читаю новости между сисколами.
Запускаю ридер, подключаю к нему strace и читаю новости между сисколами.
Хотелось бы добавить. Если процесс уже запущен и необходимо посмотреть какие файлы он использует в данный момент также можно пользоваться утилиткой
lsof -p .
lsof -p .
А я считаю что всё прекрасно. Идеально вписывается в мою идею. Вы же читали мои предложения.
Видимо я не очень хорошо изложил свои идеи.
На примере нано:
Создаем профиль безопасности вида
1. Статические права на
Конфигурацию nano (nanorc, ~/.nano_history)
Динамические библиотеки, используемые программой (libc и др.)
Файлы локализации
2. Динамическое право на запрошенный пользователем файл.
Результат будет хорош. Даже если нано захочет, он почитает только мой файл и свои конфиги, данные пользователя защищены. Даже если это будет аццкий троян он уничтожит только конфиг нано, и тот файл что пользователь отдал, но не всю систему.
С мплеером аналогично. Даем ему девайсы видеовывода, аудиовывода статически, остальное статически запрещаем, нефиг ему даже знать что у меня ещё принтер есть. Пусть имеет права себе в папку, и динамически получает права на запрошенный юзером фильм. Вот и всё.
Видимо я не очень хорошо изложил свои идеи.
На примере нано:
Создаем профиль безопасности вида
1. Статические права на
Конфигурацию nano (nanorc, ~/.nano_history)
Динамические библиотеки, используемые программой (libc и др.)
Файлы локализации
2. Динамическое право на запрошенный пользователем файл.
Результат будет хорош. Даже если нано захочет, он почитает только мой файл и свои конфиги, данные пользователя защищены. Даже если это будет аццкий троян он уничтожит только конфиг нано, и тот файл что пользователь отдал, но не всю систему.
С мплеером аналогично. Даем ему девайсы видеовывода, аудиовывода статически, остальное статически запрещаем, нефиг ему даже знать что у меня ещё принтер есть. Пусть имеет права себе в папку, и динамически получает права на запрошенный юзером фильм. Вот и всё.
Да, с таким профилем согласен. Одно но — для каждого приложения придется делать собственный профиль безопасности. Такая задача весьма трудоемкая, и здесь уже недалеко до аналога Apple Store — каждое приложение проверяется, плюс добавляется требование предоставить профиль безопасности и проверочные интеграционные тесты. Было бы хорошо — да, реализуемо ли в ближайшем будущем — трудно сказать.
А я про реализацию в ближайшем будущем и не говорил. Это концепция, которую надо разрабатывать и развивать.
Хорошо, тогда у меня пара вопросов (пусть даже это и не относится собственно к топику):
1. Как различать какие файлы можно редактировать, а какие нет? Например, в рамках текущей концепции я наберу «nano /etc/sudoers» и сделаю себя админом. Этого допускать нельзя, соответственно, какое-то дополнительное разграничение прав должно быть. Сейчас это решается на уровне POSIX ACL (ограничение прав пользователей) и PolicyKit (ограничение прав программ).
2. Как быть с системными процессами? Они должны работать в привилегированном режиме, и иметь доступ ко всему? Но тогда в случае их компрометации вся безопасность системы идет в лес. Сейчас это решается на уровне SELinux (доступ только к соответствующим контекстам).
1. Как различать какие файлы можно редактировать, а какие нет? Например, в рамках текущей концепции я наберу «nano /etc/sudoers» и сделаю себя админом. Этого допускать нельзя, соответственно, какое-то дополнительное разграничение прав должно быть. Сейчас это решается на уровне POSIX ACL (ограничение прав пользователей) и PolicyKit (ограничение прав программ).
2. Как быть с системными процессами? Они должны работать в привилегированном режиме, и иметь доступ ко всему? Но тогда в случае их компрометации вся безопасность системы идет в лес. Сейчас это решается на уровне SELinux (доступ только к соответствующим контекстам).
1. Читайте мой топик лучше. Программам выделяется только _часть_ прав юзера. Юзера а не рута. Если юзеру можно редактировать sudoers(он рут) то и нано выдадут. Ели не рут то программе больше чем юзеру позволено не дадут.
Ну тогда в рамках существующих технологий статические права разруливаются профилями AppArmor, а динамические права потенциально могут разруливаться PolicyKit. Потенциально — потому что PolicyKit сейчас в основном используется системными сервисами (тем же HAL), а менеджеры файловых системы его используют редко.
В идеале я вижу такой механизм:
1. Запускаю `nano /etc/passwd`. AppArmor дает доступ на чтение. Менеджер файловой системы проверяет права через PolicyKit и дает доступ.
2. Пытаюсь сохранить. AppArmor дает доступ (если есть соответствующее правило). Менеджер файловой системы опрашивает PolicyKit, и в зависимости от результата либо все-таки запрещает, либо запрашивает пароль.
Теоретически, можно обойтись без AppArmor, если менеджер файловой системы поддерживал бы профили безопасности (это ближе к подходу SELinux, который использует filesystem labeling). Тогда вся работа шла бы напрямую через PolicyKit.
В идеале я вижу такой механизм:
1. Запускаю `nano /etc/passwd`. AppArmor дает доступ на чтение. Менеджер файловой системы проверяет права через PolicyKit и дает доступ.
2. Пытаюсь сохранить. AppArmor дает доступ (если есть соответствующее правило). Менеджер файловой системы опрашивает PolicyKit, и в зависимости от результата либо все-таки запрещает, либо запрашивает пароль.
Теоретически, можно обойтись без AppArmor, если менеджер файловой системы поддерживал бы профили безопасности (это ближе к подходу SELinux, который использует filesystem labeling). Тогда вся работа шла бы напрямую через PolicyKit.
В догонку если нужно посмотреть, происходит ли обращение к какому-то файлу, удобно использовать inotify
а еще есть подсистема audit.
Её можно использовать для весьма тонкого просмотра что и где открывалось/писалось было опрошено…
people.redhat.com/sgrubb/audit/prelude.txt
Её можно использовать для весьма тонкого просмотра что и где открывалось/писалось было опрошено…
people.redhat.com/sgrubb/audit/prelude.txt
UFO just landed and posted this here
Спасибо за статью, слышал об этом инструменте, но видимо не покурил мануалы, не знал, что он умеет не только отследить системные вызовы конкретной программы)
Ребятки, а я всегда пользовался inotify-tools для такой задачи, а strace для отладки, с strace медленнее процесс работает, я считаю это не вариант.
Круто вы: ) Изобретение selinux and apparmor на хабре в прямом эфире, на костыльных конструкциях. Браво!
Ну а для ленивых можно поставить apparmor и сказать aa-genprof /usr/bin/mplayer
Не забудьте дать ему доступ на чтение к папке с фильмами. По крайней мере skype у меня живет именно в таком вот варианте, под aa. По идее стоит туда же определить броузер.
Ну а для ленивых можно поставить apparmor и сказать aa-genprof /usr/bin/mplayer
Не забудьте дать ему доступ на чтение к папке с фильмами. По крайней мере skype у меня живет именно в таком вот варианте, под aa. По идее стоит туда же определить броузер.
Лично я ничего протива AppArmor не имею, хотя и настораживает, что Novell уволила оригинальных разработчиков. Впрочем, разработка не остановилась, и новые фичи появляются.
Но все-таки AppArmor — это серверный компонент, в нем нет той интерактивности, которую предполагал автор топика по безопасности. Т.е. он не позволяет временно повышать привилегии, причем только на необходимом уровне, а не давать полные права рута. Единственный путь — предварительно создать нужные роли.
Про это то же говорилось. Если вы дали mplayer-у доступ в сеть и доступ к папке с фильмами, то нет гарантии, что он не сольет домашнее порно в инет. Вариант, что домашнее порно не стоит хранить в папке с фильмами, учитывается, но не снимает первоначального вопроса.
Но все-таки AppArmor — это серверный компонент, в нем нет той интерактивности, которую предполагал автор топика по безопасности. Т.е. он не позволяет временно повышать привилегии, причем только на необходимом уровне, а не давать полные права рута. Единственный путь — предварительно создать нужные роли.
Не забудьте дать ему доступ на чтение к папке с фильмами.
Про это то же говорилось. Если вы дали mplayer-у доступ в сеть и доступ к папке с фильмами, то нет гарантии, что он не сольет домашнее порно в инет. Вариант, что домашнее порно не стоит хранить в папке с фильмами, учитывается, но не снимает первоначального вопроса.
Никакого «все таки», безопасники: ) С чего вы там решили, что apparmor серверный?
Успокойтесь со своими гениальными мыслями и изучите долбаный selinux, и будут вам гарантии.
Успокойтесь со своими гениальными мыслями и изучите долбаный selinux, и будут вам гарантии.
«Серверный» в данном контексте означает, что система работает без взаимодействия с пользователем. И SELinux и AppArmor работают в ядре, и напрямую не могут ничего запрашивать у пользователя. Максимум «интерактивности», которую добавили разработчики — это уведомление пользователей об ошибках доступа (apparmor-notify, setroubleshoot).
strace не совсем аналог filemon-а. Он полезен только если вы знаете что хотите найти. Если же вам неизвестно какой процесс нужен и надо следить в рил-тайме + статистика, то strace не подходит.
Не спорю. По моему мнению, лучший кандидат на «реал-тайм + статистика» — SystemTap. Но я не стал про него даже упоминать, т.к. он требует debug-версию ядра.
Конечно, еще есть /proc/sys/vm/block_dump — достаточно хардкорный, но рабочий метод. Также можно упомянуть inotify, но это все-таки другое.
Конечно, еще есть /proc/sys/vm/block_dump — достаточно хардкорный, но рабочий метод. Также можно упомянуть inotify, но это все-таки другое.
тем удивительнее постоянно слышать на форумах — есть ли аналог Sysinternal Filemon. В данной статье я
В данной статье вы продемонстрировали текстовую утилиту для отладки, которая, как уже правильно сказали выше, хороша, если вы знаете, что ищете, и где (в каком процессе) оно находится. А так же показали, какие костыли приделать к strace (sed, grep et al), чтобы ее вывод можно было читать.
И — что самое нелепое — ведь хорошая, полезная статья бы была, если бы не это нелепое сравнение c Filemon. Это примерно как недоумевать, почему спрашивают об аналоге MS Visual Studio под Linux, а затем написать о vim.
Многие разработчики знают filemon, но не знают strace и другие утилиты. Достаточно посмотреть в гугле количество запросов «filemon linux». И везде одни и те же советы — используйте strace, lsof, inotify etc.
К слову сказать, прямые аналоги есть, например File monitoring with Mortadelo and SystemTap. Но SystemTap использует debug-версию ядра, поэтому я его упомянул лишь в постскриптуме.
К слову сказать, прямые аналоги есть, например File monitoring with Mortadelo and SystemTap. Но SystemTap использует debug-версию ядра, поэтому я его упомянул лишь в постскриптуме.
Sign up to leave a comment.
Мониторинг доступа к файлам