Описание данной возможности: docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html
Изучая скрипт файл, я обнаружил некоторые проблемы с безопасностью.
Скрипт, запускаемый через init.d, запускается с root правами. Если владелец jar-файла пользователь, то запуск java уже происходит от пользователя.
# Determine the user to run as if we are root
# shellcheck disable=SC2012
[[ $(id -u) == "0" ]] && run_user=$(ls -ld "$jarfile" | awk '{print $3}')
Но т.к. владелец jar-файла тот же пользователь, он может перезаписать сам jar-файл, который одновременно является shell-скриптом. И при старте операционной системы этот скрипт запустится с правами root. Это может быть критично, т.к. если в java-приложении есть уязвимость, в худшем случае взломщик должен остаться с правами приложения, а здесь появляется возможность повышения привилегий.
Я написал в багтрекер, но разработчик предлагает просто делать файл немодифицируемым через «chattr +i» и описать это в документации.
Как вы думаете, насколько эта уязвимость серьезная? Что стоит сделать, как правильно поступать?
Как мне кажется, надо init.d скрипт держать отдельно от jar и в другом каталоге, доступном только root.
Скрипт на github.
А ещё, launch-скрипт загружает .conf файл, лежащий в том же каталоге где и jar, через «source», интерпретируя его через bash:
[[ -r "${jarfolder}/${configfile}" ]] && source "${jarfolder}/${configfile}"
То есть там можно писать полноценный скриптовый код, который также будет исполняться с правами root при запуске сервиса через init.d.
Получается, чтобы обеспечить защиту, надо будет обязательно создавать conf-файл, даже если он не требуется, и запрещать его модификацию через «chattr +i».
Комментарии (12)
grossws
15.01.2016 23:39+1Вспомнилось, как сломав pam использовали «уязвимость» во внутреннем сервисе (доступ был только через vpn), который умел «читать» конфиги на jruby и был запущен с правами рута.
scrutari
16.01.2016 10:55А с systemd сервисами есть такая проблема?
grossws
16.01.2016 14:56+2Откуда? В
<some-service>.service
пишите:[Unit] Description=Some java service [Service] StartExec=/usr/bin/java -jar some-service.jar --param1 val1 .... User=some-user
scrutari
16.01.2016 18:36+1Почему бы тогда не использовать systemd вместо скриптов в init.d? :)
Borz
16.01.2016 19:00в скриптах в init.d можно через start-stop-daemon указывать под кем запускаться.
grossws
16.01.2016 19:37Да, когда он есть. Но в дистрибутивах с systemd полностью отпала необходимость этого геморроя, к счастью.
gurinderu
16.01.2016 11:07+1А добавить su -c в init.d script можно?
ivnik
18.01.2016 09:52Да, там это уже сделано. Проблема в том, что владелец скрипта (скрипт это и есть jar-файл) пользователь, а скрипт запускается с привилегиями root.
start-stop-daemon --start --quiet --chuid "$run_user"
А run_user определяется по владельцу jar-файла:
[[ $(id -u) == "0" ]] && run_user=$(ls -ld "$jarfile" | awk '{print $3}')
vsb
18.01.2016 12:39Не очень понятно — почему у этого файла владелец пользователь, а не root? Сделайте владельцем root-а, пользователю дайте права на чтение и всё.
PS всё, понял. Да, странное решение. Пользователь, под которым запускается файл, наверное должен прописываться где-то отдельно, а не выводиться из владельца файла.
sergey-b
Мне кажется, что проще использовать возможности binfmt и запускать jar-ы как обычные исполняемые файлы.