Bad system call android

Контейнеры и безопасность: seccomp

Для работы с потенциально опасными, непроверенными или просто «сырыми» программами часто используются так называемые песочницы (sandboxes) — специально выделенные среды с жёсткими ограничениями. Для запускаемых в песочницах программ обычно сильно лимитированы доступ к сети, возможность взаимодействия с операционной системой на хост-машине и считывать информацию с устройств ввода-вывода.

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

Но контейнер (даже несмотря на большое количество общих черт) полным аналогом песочницы не является — уже хотя бы потому, что песочницы, как правило, «заточены» под конкретные приложения, а контейнеризация представляет собой более универсальную технологию. И приложение, запущенное в контейнере, вполне может получить доступ к ядру и компрометировать его. Именно поэтому в современных инструментах контейнеризации используются механизмы для повышения уровня безопасности. В сегодняшней статье мы бы хотели поговорить об одном из таких механизмов — seccomp.

Сначала мы разберём принципы работы seccomp, а затем продемонстрируем, как он используется в Docker.

Seccomp: первое знакомство

Seccomp (сокращение от secure computing) — механизм ядра Linuх, позволяющий процессам определять системные вызовы, которые они будут использовать. Если злоумышленник получит возможность выполнить произвольный код, seccomp не даст ему использовать системные вызовы, которые не были заранее объявлены.

Seccomp — разработка Google. Он используется, в частности, в браузере Google Chrome для запуска плагинов.

Для активации seccomp используется системный вызов prctl().

Посмотрим, как это работает, на примере простой программы:

Сохраним эту программу под именем seccomp1.c, скомпилируем и запустим:

Мы увидим на консоли следующий вывод:

Чтобы понять, откуда взялся именно такой вывод, воспользуемся strace:

Итак, что же произошло? С помощью системного вызова prctl мы активировали seccomp и включили строгий режим. После этого наша программа попыталась узнать PID текущего процесса с помощью системного вызова getpid(), но наложенные ограничения не дали этого сделать: процесс получил сигнал SIGKILL и был тут же завершён.

Как видим, seccomp прекрасно справляется со своими задачами. Но строгий режим неудобен тем, что не даёт возможности выбирать, какие системные вызовы разрешать, а какие — нет. Для решения этой задачи мы можем воспользоваться механизмом BPF (Berkeley Packet Filters).

Seccomp и фильтры BPF

Механизм BPF (сокращение от Berkeley Packet Filters) был изначально создан для фильтрации сетевых пакетов, но впоследствии сфера его применения существенно расширилась. Сегодня BPF используется, например, для трассировки ядра Linux (вот интересная публикация на эту тему в блоге Брендана Грегга). В 2012 году он был интегрирован с seccomp; появилась расширенная версия, которая так и называется — seccomp-bpf.

Писать для BPF — дело очень сложное (кое-что об этом можно почитать, например, здесь). Мы же особенности синтаксиса BPF обсуждать не будем (эта тема выходит далеко за рамки нашей статьи) и воспользуемся библиотекой libseccomp, которая предоставляет простой и удобный API для фильтрации системных вызовов.

Устанавливается она при помощи стандартного менеджера пакетов:

Попробуем теперь написать небольшую программу:

Прокомментируем этот код построчно.

Здесь мы инициализируем фильтр и указываем, какое действие нужно осуществлять по умолчанию — в нашем случае это SCMP_ACT_KILL, то есть немедленная остановка процесса, который выполнит запрещённый системный вызов.

Далее идут правила seccomp; в них мы указываем системные вызовы, которые будет разрешено выполнять нашему процессу:

Далее мы активируем правила:

Как и в предыдущем примере, мы пытаемся вывести на консоль PID текущего процесса. Но получится ли у нас это сделать?

Скомпилируем и запустим программу:

Мы увидим следующий вывод:

Что произошло во время выполнения этой программы? Как и в предыдущем случае, ответить на этот вопрос нам поможет strace:

Мы видим, что сработал фильтр: процесс выполнил системный вызов getpid, запрещённый правилами, после чего был тут же остановлен.

Чтобы лучше понять, как работают фильтры seccomp, в качестве действия по умолчанию в коде полезно указать не SCMP_ACT_KILL, а SCMP_ACT_TRAP:

Вывод strace будет куда более подробным:

В нашем случае (ОС Ubuntu 16.04, ядро 4.4.) в выводе прямо указывается запрещённый системный вызов, попытка выполнения которого повлекла за собой остановку процесса: si_syscall=__NR_getpid.

В других дистрибутивах и в других версиях ядра в выводе может быть приведено не имя системного вызова, а его номер из файла /asm/unistd.h.

Seccomp в Docker

В предыдущих разделах мы разобрали основные принципы работы seccomp. Рассмотрим теперь на примере Docker, как seccomp используется в конкретных инструментах контейнеризации.

Впервые профили seccomp для контейнеров появились в runc, о котором мы уже писали.

В Docker Engine они были добавлены начиная с версии 1.10.

По умолчанию во всех контейнерах Docker заблокированы 44 системных вызова (всего в современных 64-битных Linux-системах несколько сотен системных вызовов). К числу запрещённых относится, например, системный вызов reboot(): вряд ли можно представить себе ситуацию, когда требуется перезагрузить ОС на хост-машине из контейнера.

Ещё один хороший пример — системный вызов keyctl(), для которого не так давно была обнаружена уязвимость (CVE 2016-0728). Теперь в Docker он блокируется по умолчанию.

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

Именно поэтому в контейнерах предусмотрена возможность фильтрации системных вызовов. Все фильтры прописываются в конфигурационных файлах в формате JSON.

Приведём простой пример:

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

Сохраним этот файл под именем config.json и попытаемся запустить контейнер с прописанными выше настройками seccomp:

Как видим, фильтр сработал в соответствии со сформулированными правилами: запрещённый системный вызов chmod был блокирован.

Заключение

В этой статье мы рассказали, как работает seccomp и как он используется в Docker. Если у вас есть вопросы, замечания и пожелания — добро пожаловать в комментарии.

В заключение мы, как обычно, приводим полезные ссылки для желающих узнать больше:

Источник

screen throws «Bad system call» on Android Pie #4414

Comments

jean commented Oct 11, 2019

Problem description
Screen startup shows Bad system call message, and screen subsequently terminates.
(Same as #3156)

Steps to reproduce
Run screen .

Additional information

Depending on problem, additional information may be requested:

1. Android warning/error log: logcat -d «*:W» .

1. Output of strace: strace -fv -s 2048 -o strace.log .
2. If program write it’s own log files, you may need to attach them.

The text was updated successfully, but these errors were encountered:

xeffyr commented Oct 11, 2019

Seems like @fornwall deleted my patch: 0788922

xeffyr commented Oct 13, 2019

Now it should be fixed. pkg upgrade

rogerxxxx commented Jan 8, 2020 •

Ever since this bug was initialized, I’ve been getting the bad system call with screen.

I have updated, uninstalled, reinstalled screen, and the bug persists.

Found a workaround:
$ proot -0 screen

Not pretty, but does complain setuid/setgid error when not using the «-0» option.

Probably better yet, added the following to $HOME/.bashrc
alias screen=»proot —root-id screen» # Without proot, screen tries accessing illegal setuid/setgid

. just need to remember the alias is set when the bug gets fixed, if ever.

Seems this bug is still on-going.

xeffyr commented Jan 8, 2020 •

@rogerxxxx It is fixed (I don’t have bad system call on Pie). Just make sure that your packages are not installed from termux.net (this repo will never receive a fix).

Package version should be 4.7.0-2 .

rogerxxxx commented Jan 8, 2020

On Android, I simply issue «pkg update» and «pkg upgrade» commands, by default all goes to termux.net.

I do not understand why the main repo would not receive in update/fix when the repo apparently always receives fixes/upgrades.

xeffyr commented Jan 8, 2020 •

termux.net is considered as legacy environment and is not receiving any updates — #4467. It is for Android 5-6 only.

For Android 7+ do termux-upgrade-repo for switching.

rogerxxxx commented Jan 8, 2020 •

Thanks. I understand now the Termux version release cycle is based on Android version utilized, preserving «what works» for people stuck with older Android versions.

(I too am now stuck within this Android cycle for this Samsung device, having no new Android versions installed after this present Android release..)

xeffyr commented Jan 8, 2020

Android versions below Oreo do not require this fix anyway (seccomp filter was introduced in Android 8.0).

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Saurabh Sharma Software Developer, Voracious Reader and Caffeine Addict

Happy Coding Discussion on Android Framework(Generic and MultiMedia), Java, JNI, C++ and Python related topic

Thursday, 23 February 2017

Native crash (Tombstone) in android AOSP

Tombstone file in /data/tombstones

adb pull /data/tombstones .

Full Coredump file in /sdcard/app_dump

adb pull /sdcard/app_dump .

AP logs (Both of the following approaches are OK)

Manually collected logs (not available in “user” build)

adb shell dmesg >kernel_log.txt

adb shell su ^^ /proc/kmsg >> kernel_log.txt

adb logcat –b main –b system –b radio –b events >logcat_logs.txt

Aplogd collected logs (not available in “user” build)

adb pull /sdcard/logger .

adb pull /data/logger .

adb bugreport >bugreport.txt

Usage: arm-linux-androideabi-addr2line [option(s)] [addr(s)]
Convert addresses into line number/file name pairs.
If no addresses are specified on the command line, they will be read from stdin
The options are:

• @ Read options from
• -a —addresses Show addresses
• -b —target= Set the binary file format
• -e —exe= Set the input file name (default is a.out)
• -i —inlines Unwind inlined functions
• -j —section= Read section-relative offsets instead of addresses
• -p —pretty-print Make the output easier to read for humans
• -s —basenames Strip directory names
• -f —functions Show function names
• -C —demangle[=style] Demangle function names
• -h —help Display this information
• -v —version Display the program’s version

16 comments:

hello,
i just want to say that you have clearly mention the process very clearly and i also found it is very much easy to understand. keep sharing.

The Angular Training covers a wide range of topics including Components, Angular Directives, Angular Services, Pipes, security fundamentals, Routing, and Angular programmability. The new Angular TRaining will lay the foundation you need to specialise in Single Page Application developer. Angular Training

backtrace:
#00 pc 00044320 /system/lib/libc.so (tgkill+12)
#01 pc 00041f21 /system/lib/libc.so (pthread_kill+32)
#02 pc 0001ba4f /system/lib/libc.so (raise+10)
#03 pc 00018bf1 /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000167b0 /system/lib/libc.so (abort+4)
#05 pc 0001a663 /system/lib/libc.so (__libc_fatal+16)
#06 pc 0001a67b /system/lib/libc.so (__fortify_chk_fail+18)
#07 pc 00016b4c /system/lib/libc.so (__memcpy_chk_fail+16)
#08 pc 00000849 /data/app/com.exe.jazz-1/lib/arm/libhellojava_jni.so (Java_com_exe_jazz_Hellojava_crash+36)
#09 pc 000ea8a9 /system/lib/libart.so (art_quick_generic_jni_trampoline+40)
#10 pc 000e61b1 /system/lib/libart.so (art_quick_invoke_stub_internal+64)
#11 pc 003eb4e3 /system/lib/libart.so (art_quick_invoke_stub+170)
#12 pc 007fc9ec [stack]
stack:
ff8827dc 00000000
ff8827e0 00000000
ff8827e4 00000000
Command:
/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin$ ./arm-linux-androideabi-addr2line -C -f -e
/out/target/product/falcon/symbol/lib/libhellojava_jni.so 00000849
Output:
Java_com_sks_softsolution_Hellojava_crash
.
so after executing the above command will it directly give the line number and the file name where there is a problem ?

Nice article, you showed difficult concept in a simple way.

Hi
Will there be any core dump for Java app file

Источник

Bad system call #4065

Comments

ourarash commented Jul 19, 2019 •

Problem description
This gives me bad system call:

npm install https://github.com/ourarash/get-cursor-position.git

I did apt update && apt upgrade but still get the error.
Steps to reproduce

npm install https://github.com/ourarash/get-cursor-position.git

Expected behavior
Install the package

Additional information
Post output of command termux-info .

Depending on problem, additional information may be requested:

1. Android warning/error log: logcat -d «*:W» .
2. Output of strace: strace -fv -s 2048 -o strace.log .
3. If program write it’s own log files, you may need to attach them.

The text was updated successfully, but these errors were encountered:

Grimler91 commented Jul 19, 2019

Are you using a custom rom? Are you rooted?

You could try upgrading to the android-7 repo by running termux-upgrade-repo and then trying again

ourarash commented Jul 19, 2019 •

No, I’m using non rooted Samsung Galaxy note 8.

I tried termux-upgrade-repo, but still the same problem.

Grimler91 commented Jul 19, 2019

I was having this problem when I was using a particular custom rom for the galaxy s8+. The bad system call was kill() , which was weird cause it shouldn’t be blocked according to the syscall blacklist, but I’m not a seccomp expert so maybe I’m missing something.
The problem disappeared after I flashed another rom so I figured it was a problem with that particular rom.

Could you install gdb and this debug build of nodejs: https://grimler.se/nodejs-dbg_12.4.0-1_aarch64.deb
And post the output of
gdb -ex=run -ex=bt —args npm install https://github.com/ourarash/get-cursor-position.git
to confirm it’s the same issue as I’ve encountered before?

ourarash commented Jul 19, 2019 •

I get this for installing the debug node package:

Does this command work for you?

npm install https://github.com/ourarash/get-cursor-position.git

xeffyr commented Jul 19, 2019

I get this for installing the debug node package:

Источник