Summary: | bwrap игнорирует PATH при поиске запускаемых приложений | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Anton Farygin <rider> |
Component: | bubblewrap | Assignee: | Yuri N. Sedunov <aris> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P5 | CC: | aris, cas, iv, lav, ldv, rider, underwit, zerg |
Version: | unstable | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
See Also: | https://bugzilla.altlinux.org/show_bug.cgi?id=51514 | ||
Bug Depends on: | |||
Bug Blocks: | 34937 |
Description
Anton Farygin
2020-02-27 18:55:01 MSK
В glibc это поведение привносится: commit 69a1f59f8b86ee9b031c74fcd3d218605ba5be93 Author: Dmitry V. Levin <ldv@altlinux.org> Date: Mon Oct 20 11:06:36 2008 +0000 owl-alt-sanitize-env Sanitize the environment in a paranoid way. Да, в первом примере запуск bwrap был с опечаткой, но по сути ничего не меняется: $ bwrap --unshare-net --new-session --proc /proc --dev /dev --bind /tmp/.private/rider /tmp --setenv TMPDIR /tmp --setenv TMP /tmp --setenv TEMPDIR /tmp --setenv TEMP /tmp --tmpfs /run --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib /lib --ro-bind /lib64 /lib64 --ro-bind /etc /etc --ro-bind /opt /opt --ro-bind /home /home --ro-bind /var /var --ro-bind /home/rider/.opam/ocaml-base-compiler /home/rider/.opam/ocaml-base-compiler --bind /home/rider /home/rider --bind /home/rider/.cache/dune /home/rider/.cache/dune ocaml Creating root mount point creating new namespace forking for child launch executable ocaml bwrap: execvp ocaml: No such file or directory Для чего используется bwrap в opam можно почитать тут: https://opam.ocaml.org/doc/FAQ.html#Why-does-opam-require-bwrap 2ldv: хотелось бы, что бы bwrap у нас заработал так же как, как и в других дистрибутивах. Из вышепроцитированного у меня сложилось ощущение, что это уязвимость в bwrap, причём в точности того класса, который наш ld.so затыкает. тогда это хороший повод сходить в апстрим, если у тебя есть понимание, в чём заключается уязвимость и как её эксплуатировать. Код в нём конечно ужасен, но именно в данном месте уязвимости быть не должно - bwrap в этом месте работает уже не под рутом. /* This acquires the privileges that the bwrap will need it to work. * If bwrap is not setuid, then this does nothing, and it relies on * unprivileged user namespaces to be used. This case is * "is_privileged = FALSE". * * If bwrap is setuid, then we do things in phases. * The first part is run as euid 0, but with fsuid as the real user. * The second part, inside the child, is run as the real user but with * capabilities. * And finally we drop all capabilities. * The reason for the above dance is to avoid having the setup phase * being able to read files the user can't, while at the same time * working around various kernel issues. See below for details. */ Есть предложение реализовать в bwrap самостоятельную обработку PATH по аналогии с execvpe из glibc. Дима, как по твоему, что лучше - тащить реализацию поиска приложение из glibc в bubblewrap или откатить в нашем glibc игнорирование PATH в execvpe для суидных придожений ? ping Как видно, Дима предлагает самим выбрать из одного варианта. (Ответ для Sergey V Turchin на комментарий #8) > Как видно, Дима предлагает самим выбрать из одного варианта. Тогда перенесите в него поиск файла по пути, пожалуйста, из glibc, что бы нам не лезть в старый код в самом glibc. Сделал исправление. Пропустите сборку #251987 У меня заработало. Например, установленный из flatpak kdenlive стал запускатся, bubblewrap-0.4.1-alt2 -> sisyphus: Wed May 20 2020 Ivan Razzhivin <underwit@altlinux> 0.4.1-alt2 - fix run path (Closes: 38163) |