Configuring Linux
Comments 26
+1
полезно. Немногие знают про этот замечательный инструмент, шикарно помогает при отладке странных глюков в приложениях, особенно когда одного debug-лога не хватает
+2
Я им пользуюсь, чтобы проверить работу вебсервера, когда непонятно, почему при внешне правильном конфиге он выдаёт, например, 404 ошибку.
+6
Ха, я настолько суров, что читаю RSS через strace.

Запускаю ридер, подключаю к нему strace и читаю новости между сисколами.
+5
Хотелось бы добавить. Если процесс уже запущен и необходимо посмотреть какие файлы он использует в данный момент также можно пользоваться утилиткой
lsof -p .
+2
А я считаю что всё прекрасно. Идеально вписывается в мою идею. Вы же читали мои предложения.
Видимо я не очень хорошо изложил свои идеи.
На примере нано:
Создаем профиль безопасности вида

1. Статические права на
Конфигурацию nano (nanorc, ~/.nano_history)
Динамические библиотеки, используемые программой (libc и др.)
Файлы локализации

2. Динамическое право на запрошенный пользователем файл.

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

С мплеером аналогично. Даем ему девайсы видеовывода, аудиовывода статически, остальное статически запрещаем, нефиг ему даже знать что у меня ещё принтер есть. Пусть имеет права себе в папку, и динамически получает права на запрошенный юзером фильм. Вот и всё.
0
Да, с таким профилем согласен. Одно но — для каждого приложения придется делать собственный профиль безопасности. Такая задача весьма трудоемкая, и здесь уже недалеко до аналога Apple Store — каждое приложение проверяется, плюс добавляется требование предоставить профиль безопасности и проверочные интеграционные тесты. Было бы хорошо — да, реализуемо ли в ближайшем будущем — трудно сказать.
0
А я про реализацию в ближайшем будущем и не говорил. Это концепция, которую надо разрабатывать и развивать.
0
Хорошо, тогда у меня пара вопросов (пусть даже это и не относится собственно к топику):

1. Как различать какие файлы можно редактировать, а какие нет? Например, в рамках текущей концепции я наберу «nano /etc/sudoers» и сделаю себя админом. Этого допускать нельзя, соответственно, какое-то дополнительное разграничение прав должно быть. Сейчас это решается на уровне POSIX ACL (ограничение прав пользователей) и PolicyKit (ограничение прав программ).

2. Как быть с системными процессами? Они должны работать в привилегированном режиме, и иметь доступ ко всему? Но тогда в случае их компрометации вся безопасность системы идет в лес. Сейчас это решается на уровне SELinux (доступ только к соответствующим контекстам).
0
1. Читайте мой топик лучше. Программам выделяется только _часть_ прав юзера. Юзера а не рута. Если юзеру можно редактировать sudoers(он рут) то и нано выдадут. Ели не рут то программе больше чем юзеру позволено не дадут.
0
Ну тогда в рамках существующих технологий статические права разруливаются профилями AppArmor, а динамические права потенциально могут разруливаться PolicyKit. Потенциально — потому что PolicyKit сейчас в основном используется системными сервисами (тем же HAL), а менеджеры файловых системы его используют редко.

В идеале я вижу такой механизм:
1. Запускаю `nano /etc/passwd`. AppArmor дает доступ на чтение. Менеджер файловой системы проверяет права через PolicyKit и дает доступ.
2. Пытаюсь сохранить. AppArmor дает доступ (если есть соответствующее правило). Менеджер файловой системы опрашивает PolicyKit, и в зависимости от результата либо все-таки запрещает, либо запрашивает пароль.

Теоретически, можно обойтись без AppArmor, если менеджер файловой системы поддерживал бы профили безопасности (это ближе к подходу SELinux, который использует filesystem labeling). Тогда вся работа шла бы напрямую через PolicyKit.
+2
В догонку если нужно посмотреть, происходит ли обращение к какому-то файлу, удобно использовать inotify
0
Познавательно для многих.
Но не для всех, к сожалению…

Для упорствующих нужно бы показать выхлоп starce на пару сотен строк…
Потому как в системе (если для кого новость) есть еще пару (сотен) программ, кроме плеера…
;)
0
Спасибо за статью, слышал об этом инструменте, но видимо не покурил мануалы, не знал, что он умеет не только отследить системные вызовы конкретной программы)
+2
Ребятки, а я всегда пользовался inotify-tools для такой задачи, а strace для отладки, с strace медленнее процесс работает, я считаю это не вариант.
0
Круто вы: ) Изобретение selinux and apparmor на хабре в прямом эфире, на костыльных конструкциях. Браво!

Ну а для ленивых можно поставить apparmor и сказать aa-genprof /usr/bin/mplayer
Не забудьте дать ему доступ на чтение к папке с фильмами. По крайней мере skype у меня живет именно в таком вот варианте, под aa. По идее стоит туда же определить броузер.
0
Лично я ничего протива AppArmor не имею, хотя и настораживает, что Novell уволила оригинальных разработчиков. Впрочем, разработка не остановилась, и новые фичи появляются.

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

Не забудьте дать ему доступ на чтение к папке с фильмами.

Про это то же говорилось. Если вы дали mplayer-у доступ в сеть и доступ к папке с фильмами, то нет гарантии, что он не сольет домашнее порно в инет. Вариант, что домашнее порно не стоит хранить в папке с фильмами, учитывается, но не снимает первоначального вопроса.
+1
Никакого «все таки», безопасники: ) С чего вы там решили, что apparmor серверный?

Успокойтесь со своими гениальными мыслями и изучите долбаный selinux, и будут вам гарантии.
0
«Серверный» в данном контексте означает, что система работает без взаимодействия с пользователем. И SELinux и AppArmor работают в ядре, и напрямую не могут ничего запрашивать у пользователя. Максимум «интерактивности», которую добавили разработчики — это уведомление пользователей об ошибках доступа (apparmor-notify, setroubleshoot).
+1
strace не совсем аналог filemon-а. Он полезен только если вы знаете что хотите найти. Если же вам неизвестно какой процесс нужен и надо следить в рил-тайме + статистика, то strace не подходит.
0
Не спорю. По моему мнению, лучший кандидат на «реал-тайм + статистика» — SystemTap. Но я не стал про него даже упоминать, т.к. он требует debug-версию ядра.

Конечно, еще есть /proc/sys/vm/block_dump — достаточно хардкорный, но рабочий метод. Также можно упомянуть inotify, но это все-таки другое.
0
Я думаю всё-таки надо было в статье хотя бы вскользь упомянуть эти инструменты. Наеюсь доки по ним кто захочет сам найдёт, а вот сформировать запрос гуглу на поиск заранее неизвестной софтины иногда проблематично.
0
Сделано, спасибо за напоминание. Если вы знаете какие-то другие инструменты, дайте знать, если не трудно. Кстати, filemon был когда-то и под Линукс, но потом из-за модификаций ядра он перестал работать.
+1
тем удивительнее постоянно слышать на форумах — есть ли аналог Sysinternal Filemon. В данной статье я

В данной статье вы продемонстрировали текстовую утилиту для отладки, которая, как уже правильно сказали выше, хороша, если вы знаете, что ищете, и где (в каком процессе) оно находится. А так же показали, какие костыли приделать к strace (sed, grep et al), чтобы ее вывод можно было читать.
И — что самое нелепое — ведь хорошая, полезная статья бы была, если бы не это нелепое сравнение c Filemon. Это примерно как недоумевать, почему спрашивают об аналоге MS Visual Studio под Linux, а затем написать о vim.
0
Многие разработчики знают filemon, но не знают strace и другие утилиты. Достаточно посмотреть в гугле количество запросов «filemon linux». И везде одни и те же советы — используйте strace, lsof, inotify etc.

К слову сказать, прямые аналоги есть, например File monitoring with Mortadelo and SystemTap. Но SystemTap использует debug-версию ядра, поэтому я его упомянул лишь в постскриптуме.
Only those users with full accounts are able to leave comments., please.