Мониторинг доступа к файлам

    Зачастую пользователям и системным администратором необходимо отслеживать, к каким файлам обращается приложение. В Linux-е уже есть все средства для этого, и тем удивительнее постоянно слышать на форумах — есть ли аналог Sysinternal Filemon. В данной статье я опишу использование утилиты strace, и рассмотрю ряд моментов, которые ускользают от некоторых пользователей, полагающих, что приложениям надо ограничивать права даже на чтение, например, ограничить доступ mplayer-а только к показываемому фильму.

    strace — это трассировщик системных вызовов и сигналов. Для работы с файлами используется системный вызов «open», и соответственно, необходимо отслеживать только его. Пример команды:
    $ strace -xf -eopen -o /path/to/log /path/to/program

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

    Мониторинг текстового редактора nano


    Для начала посмотрим, к каким файлам обращается простейший текстовой редактор nano:
    $ strace -xf -eopen -o out.log nano temp.txt
    $ sed -n 's/.*open(\(.*\))\s*=.*/\1/p' out.log | sort

    Командой sed мы преобразуем лог в более краткий формат для читабельности, и сортируем строчки. В итоге должно вывестись что-то типа такого:
    "/etc/ld.so.cache", O_RDONLY
    "/etc/nanorc", O_RDONLY
    "/home/nuald/.nano_history", O_RDONLY
    "/home/nuald/.nano_history", O_WRONLY|O_CREAT|O_TRUNC, 0666
    "/home/nuald/.nanorc", O_RDONLY
    "/lib/libc.so.6", O_RDONLY
    "/lib/libdl.so.2", O_RDONLY
    "/lib/libncursesw.so.5", O_RDONLY
    "/lib/terminfo/x/xterm", O_RDONLY
    "temp.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666
    "/usr/lib/gconv/gconv-modules.cache", O_RDONLY
    "/usr/lib/locale/en_US.utf8/LC_ADDRESS", O_RDONLY
    ... другие библиотеки для работы с локалью
    "/usr/lib/locale/locale-archive", O_RDONLY
    "/usr/share/locale/en/LC_MESSAGES/nano.mo", O_RDONLY
    ... другие файлы локализации
    "/usr/share/locale/locale.alias", O_RDONLY

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

    Т.е. в процессе работы программам нужен доступ к достаточному большому количеству файлов, и ограничение доступа на чтение отрицательно повлияет на работоспособность программ.

    Мониторинг видеопроигрывателя mplayer


    Теперь попробуем запустить mplayer и проверить те файлы, в которые он только пишет. Возможно, это нам даст возможность составить нужный безопасный профиль работы программы.

    $ strace -xf -eopen -o out.log mplayer test.mp4
    $ sed -n 's/.*open(\(.*\))\s*=.*/\1/p' out.log | grep -v O_RDONLY | sort

    "/dev/3dfx", O_RDWR
    "/dev/fb0", O_RDWR
    "/dev/mga_vid", O_RDWR
    "/dev/mga_vid", O_RDWR
    "/dev/shm/pulse-shm-3056117003", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0400
    "/home/nuald/.mplayer/config", O_WRONLY|O_CREAT|O_EXCL, 0666
    "/home/nuald/.pulse-cookie", O_RDWR|O_CREAT|O_NOCTTY, 0600

    Здесь мы командой grep ограничили вывод, и не включали файлы, которые были открыты с флагом O_RDONLY (только на чтение). Как видите, и здесь не все так гладко — mplayer-у приходится писать в другие файлы, и возможно ограничение доступа полностью его сломает, и он не сможет воспроизводить видео. Так что приведенную выше идею об ограничении доступа не так просто будет реализовать, и точно не реализовать в ее изначальном смысле.

    Заключение


    В этом небольшом эскурсе была приведена лишь одна область применения strace. У данной программы есть много замечательных способностей, и она может позволить избавиться от бессонных ночей в поисках причин неработоспобности приложений даже без применения отладчика. Это инструмент, который должен знать любой Linux-разработчик, и надеюсь, что это принесет вам пользу в борьбе с многочисленными багами, и повысить качество разрабатываемого программного обеспечения.

    P.S. Приведу список других инструментов, полезных для мониторинга доступа к файлам:
    • SystemTap — инструментарий для сбора статистики. Острожно — требует debug-версии ядра (из него он берет отладочные символы и информацию). Пример мониторинга операции «open» описан в документации.
    • /proc/sys/vm/block_dump — Отладка блокового ввода-вывода.
    • inotify -подсистема ядра Linux, которая позволяет получать уведомления об изменениях в файловой системе. Можно использовать через inotify tools.
    Поделиться публикацией

    Комментарии 26

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

          Запускаю ридер, подключаю к нему strace и читаю новости между сисколами.
            +4
            тру Админ читает нововсти через tcpdump )
            +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
                  а еще есть подсистема audit.
                  Её можно использовать для весьма тонкого просмотра что и где открывалось/писалось было опрошено…
                  people.redhat.com/sgrubb/audit/prelude.txt
                    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-версию ядра, поэтому я его упомянул лишь в постскриптуме.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое