Комментарии 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
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за статью, слышал об этом инструменте, но видимо не покурил мануалы, не знал, что он умеет не только отследить системные вызовы конкретной программы)
Ребятки, а я всегда пользовался 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-версию ядра, поэтому я его упомянул лишь в постскриптуме.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мониторинг доступа к файлам