LINUX.ORG.RU

strace 4.15

 ,


2

3

strace — утилита для диагностики и отладки программ для ОС, использующих ядро Linux. Она позволяет отслеживать и (начиная с данной версии) вмешиваться в процесс взаимодействия программы и ядра, включая происходящие системные вызовы, возникающие сигналы и изменения состояния процесса. Для своей работы strace использует механизм ptrace. Начиная с версии 4.13 формирование выпусков strace синхронизировано с выходом новых версий Linux.

Основные изменения этого релиза:

  • Реализована возможность подмены номера системного вызова и результата вызова («fault injection»). Это позволяет изучать поведение приложений в случае возникновения ошибок при выполнении различных системных вызовов. Например, данная возможность позволила выявить недостаточную проверку кода возврата вызовов mprotect() в коде glibc dynamic linker:
    $ strace -e mprotect -e fault=mprotect:when=1:error=ENOMEM cat </dev/null 
    mprotect(0xf774e000, 4096, PROT_NONE)   = -1 ENOMEM (Cannot allocate memory) (INJECTED)
    mprotect(0xf774f000, 8192, PROT_READ)   = 0
    mprotect(0x8054000, 4096, PROT_READ)    = 0
    mprotect(0xf7784000, 4096, PROT_READ)   = 0
    +++ exited with 0 +++
    
    Более подробно она рассмотрена автором прототипной реализации, сделанной в рамках GSoC 2016, и на выступлении «Can strace make you fail?» на тринадцатой конференции разработчиков свободных программ.
  • Добавлена поддержка декодирования команд ioctl(), связанных с подсистемой device mapper:
    $ strace -e trace=ioctl -v dmsetup ls 
    ioctl(3, DM_VERSION, {version=4.0.0, data_size=16384, flags=DM_EXISTS_FLAG} => {version=4.27.0, data_size=16384, flags=DM_EXISTS_FLAG}) = 0
    ioctl(3, DM_LIST_DEVICES, {version=4.0.0, data_size=16384, data_start=312, flags=DM_EXISTS_FLAG} => {version=4.27.0, data_size=339, data_start=312, flags=DM_EXISTS_FLAG, {dev=makedev(253, 0), name="dm0"}}) = 0
    dm0	(253:0)
    +++ exited with 0 +++
    
  • Добавлена поддержка декодирования значения аргумента attr системного вызова perf_event_open():
    $ strace -e trace=perf_event_open -v perf stat -e kmem:mm_page_pcpu_drain sh -c 'git gc 2>/dev/null' 
    --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=10413, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
    perf_event_open({type=PERF_TYPE_TRACEPOINT, size=PERF_ATTR_SIZE_VER3, config=398, sample_period=1, sample_type=PERF_SAMPLE_TIME|PERF_SAMPLE_CPU|PERF_SAMPLE_PERIOD|PERF_SAMPLE_RAW, read_format=PERF_FORMAT_TOTAL_TIME_ENABLED|PERF_FORMAT_TOTAL_TIME_RUNNING, disabled=1, inherit=1, pinned=0, exclusive=0, exclusive_user=0, exclude_kernel=0, exclude_hv=0, exclude_idle=0, mmap=0, comm=0, freq=0, inherit_stat=0, enable_on_exec=1, task=0, watermark=0, precise_ip=0 /* arbitrary skid */, mmap_data=0, sample_id_all=0, exclude_host=0, exclude_guest=1, exclude_callchain_kernel=0, exclude_callchain_user=0, mmap2=0, comm_exec=0, use_clockid=0, context_switch=0, write_backward=0, wakeup_events=0, config1=0, config2=0, sample_regs_user=0}, 10414, -1, -1, 0) = 3
    --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=10414, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
    
     Performance counter stats for 'sh -c git gc 2>/dev/null':
    
                 7,006      kmem:mm_page_pcpu_drain                                     
    
           2.207781396 seconds time elapsed
    
    --- SIGCHLD {si_signo=SIGCHLD, si_code=SI_USER, si_pid=10412, si_uid=0} ---
    +++ exited with 0 +++
    
  • Добавлена поддержка декодирования системных вызовов pkey_alloc(), pkey_free() и pkey_mprotect(), добавленных в Linux 4.9 (см. также).
  • Обновлена поддержка декодирования системных вызовов для архитектур arc, x32 и xtensa.
  • Переработана страница документации strace(1).

>>> Полный список изменений

>>> Сайт проекта (sourceforge)

>>> Репозиторий (sourceforge)

>>> Сообщение в списке рассылки

★★

Проверено: Shaman007 ()
Последнее исправление: sudopacman (всего исправлений: 2)

Добавлена поддержка декодирования команд ioctl()

За это отдельное спасибо :3

Fedorast
()
Ответ на: комментарий от kto_tama

В hardened-ядрах можно запретить приложениям, запущенным из под непривилегированного пользователя делать вызов ptrace. Да и в общем случае ты не можешь сделать этот вызов к приложениям, запущенным от другого пользователя(если ты не root, конечно)

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Но подмена возврата системного вызова — довольно серьезный вектор атаки. Считаю что стоило бы ограничить ее вызова только до суперпользователя вообще по умолчанию.

KennyMinigun ★★★★★
()
Ответ на: комментарий от KennyMinigun

Считаю что стоило бы ограничить ее вызова только до суперпользователя вообще по умолчанию.

А может, еще и выключить в ядре по умолчанию? Серьезный же вектор.

tailgunner ★★★★★
()
Ответ на: комментарий от KennyMinigun

ЕМНИП процесс запущенный от пользователя A имеет полный доступ к другому процессу, запущенному от того же пользователя(мы сейчас не говорим о мандатных системах контроля, где это можно пусть и частично нивелировать). strace просто использует сложившееся положение вещей, к нему претензий быть не может ИМХО

Pinkbyte ★★★★★
()

подмена кода возвращения без лд_прелоад или системтап, оууу йееах. и даже иоцтл теперь можно нормально читать, зашибись!

val-amart ★★★★★
()

Нужно! годно, это первое что берётся в руки если что-то не так пошло.

Dron ★★★★★
()
Ответ на: комментарий от KennyMinigun

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

ioway
()

Одна из самых часто используемых утилит в работе. Очень не хвататет такой на винде (во времена XP была, я знаю про apimonitor, но он на основе хуков и не перехватывает sysenter).

anonymous
()
Ответ на: комментарий от Pinkbyte

Ну да, я понимаю, что strace — всего-лишь интерфейс к ptrace. Просто суть того, что один непривилегиированный процесс может вторгнуться в ход исполнения другого такого же процесса выглядит немного небезопасно.

Я сейчас думаю о потенциальных дырах в ПО, которые позволят исполнить произвольный код в системе. И после такого зловредный код может спокойно подменять коды возврата системных вызовов.

Ситуация енсколько похожа на сигналы: процессы одного пользователя могут свободно себе сигнализировать. Вот только сигналы — более-менее IPC, а подмена возврата системных функций нечто иное.

Т.е. предложение было по просту таково, что функцию подмены возвращаемого значения сисколла (в ptrace) следовало бы ограничить до суперпользователя по умолчанию.

KennyMinigun ★★★★★
()
Ответ на: комментарий от true_admin

Но там, насколько я понимаю, вообще ptrace запрещается?

В прицинпе, для enterprise систем сгодится: ptrace там вообще не нужен, как и компилятор/дебаггер.

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 2)
Ответ на: комментарий от KennyMinigun

Щито, а как же дебажить в продакшне?

anonymous
()
Ответ на: комментарий от anonymous

последний коммит в 2012 году, не думаю, что оно работает с arm64 нормально, да и Binder за это время изменился. Хотя да, давно хочу попробовать. Вот на праздниках займусь.

melon-aerial
()
Ответ на: комментарий от KennyMinigun

вообще ptrace запрещается?

Ты можешь этим управлять, но... надо отдавать себе отчёт в том что в большинстве случаев есть угрозы гораздо более существенные. Потому что если атакующий натравил strace на твой процесс то значит ему удалось получить рута в системе. Это тебя не пугает? :). По-дефолту (дистрозависимо) ptrace можно натравливать только на себя и на дочерние процессы.

ptrace там вообще не нужен

Для меня это чуть ли не основной инструмент исследования проблем в продакшене. Потому что такой вот продакшн из говна и палок.

true_admin ★★★★★
()
Ответ на: комментарий от KennyMinigun

Делал песочницу на ptrace. Вы не правы, не рут не может вторгнуться в ход исполнения другого. Без рута другой процесс может только намеренно дать себя трейсить через PTRACE_TRACEME.

anonymous
()
Ответ на: комментарий от KennyMinigun

В ptrace не функциональности «подменить возвращаемое значение», ор только про то, чтобы произвользым способом модифицирвать код программы на лету, а strace уже реализует высокоуровневые функции, типа подмены возвращаемого значения, через через универсальную но низкоуровневую функциональность ptrace. А с точки зрения безопасности по сравнению с возможностью подставить произвольный код в программу подмена значения сисколла - это детский лепет.

anonymous
()

Хорошая новость про нужное ПО. Приходится использовать очень часто, поэтому не может не радовать, что проект развивается)

lucentcode ★★★★★
()
Ответ на: комментарий от KennyMinigun

Категорически не согласен, что ptrace вызовы не нужны в продакшене. За более чем 6 лет активного пользования strace в продакшене, благодаря последнему мне удалось найти причину просто оочень большого числа разнообразных проблем. Часто логи конкретного демона ничего путного не содержат. Или возникающие исключения вообще не обрабатываются/не могут быть обработаны. Или проблема связана с откликом какой-то третьей стороны или ещё масса других примеров. Strace в связке с tcpdump помогает очень и очень сильно. Ptrace() при всём при этом весьма дешёвый в плане оверхеда вариант и при разумном использовании даже на нагруженном сервере не приводит к локам. На счёт безопасности верно сказали - есть множество других, гораздо более опасных векторов атаки. Сам пользую grsecurity патчи на критических серверах, там отлично реализована изоляция процесса. Процесс в рамках своих прав не то, что ptrace() другому процессу не может сделать, он его даже увидеть в системе не может.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.