Комментарии 60
Не совсем понимаю в чём проблема. Это задокументированное поведение bash.
И если не валидировать ввод получается фигня. Во всех языках.
Проблемы безопасности тут нет как и самой безопасности в bash. Если уж у злоумышленника есть возможность запустить скрипт - то скопировать и исправить его и подавно. Незачем тут мудрить с пейлодом в [ ] или ( ) .
bash и shell вообще — плохие языки для написания чего-либо в принципе
Всё, что есть прекрасного в этой жизни, либо аморально, либо незаконно, либо приводит к ожирению.
а к автору скрипта, что он мудак и не смог нормально написать
и да, и нет. Может Вы знаете про VestaCP, например. https://vestacp.com Весьма неплохая панель для администрирования серверов и написана полностью на баше. Но при этом поддерживать такое количество кода попросту нереально. Отсюда и огромное количество ишьюс (в т.ч. и по безопасности) в трекере VestaCP и отказ от дальнейшей разработки продукта.
Второе пример — инит скрипты из SysV. В конечном счете, мы перешли все на системди и слава Богу. Потому что скрипты каждый писал как мог, каких-то общих подходов не было.
Выстрелить в ногу можно в любом языке, все претензии не языку,
претензии к языку, что он не предоставляет никаких средств типизации, проверок. Другой вопрос, что Вы абсолютно правы, что это и накладывает ограничения на применение шелл скриптов. Условный скрипт на 10 строчек на нем писать ок, а делать какую-то хитрую автоматизацию — ей-Богу, лучше python взять...
Такое количество кода поддерживать ничего сложного.
Вам 18 лет? Очевидно, что чем больше кода — тем сложнее поддерживать. Чем больше кода — тем более необходима модульность. Тем нужнее всякие namespace, наличие ООП на уровне языка и прочее. Это все есть в баше? Нет!
Такие вещи предусматриваются на этапе проектирования
нет. Тем более, когда ты приходишь и уже есть что-то. Есть вариант дешевый — что-то закостылять и получить результат. Правда, растет техдолг, но не нам же с ним бороться. И есть вариант дорогой — переделать все нормально. Но кто ж даст. Вот и балансируешь, аргументируя что правильно в конкретный момент времени.
У меня есть скрипты в тысячи строк.
и что? Еще раз — если есть потребность в скрипте в тысячи строк — это ОЧЕНЬ хороший аргумент бросить баш и взять что-то более вменяемое, например, полноценный язык программирования с нормальными модулями для выполнения рутинных задач. Например, тот же python.
Шел довольно выразительный язык. Для меня примером эталонного кода уже много лет является Git. Это довольно крупный проект. Но стиль программирования в нем отличается от привычного. Там используется куча своих паттернов, которые я больше ни где не встречал. Результат очень похож на обычный английский. Но чтобы так писать, по-моему нужно иметь довольно высокую квалификацию.
Чаще же его используют непрофессиональные программисты для решения каких-то своих задач автоматизации. Благо порог входа очень низкий. Поэтому не удивительно, что среднестатистический код выглядит как.
Насчёт гита — может быть, но для большинства это execute only код, без необходимости влезать в код, а тем более править его. К тому же и на Си можно было что-то подобное реализовать через макросы препроцессора. Но никто так не делает ))) Почему? Да как раз потому что надо обеспечить возможность изменения для программистов любого уровня )
Я поддерживал форк hetzner-installimage и крайне быстро упёрся в размер проекта. Не помогало ничего, главным образом нет возможности дебагер сделать для шелов.
Если уж у злоумышленника есть возможность запустить скрипт — то скопировать и исправить его и подавно.
Вы неправы от слова совсем. Типичный пример. Есть сервер. На нем есть непривилегированные пользователи. Скрипт запускается либо со sticky bit/suid или чем-то подобным, либо прописан в sudo у пользователя на исполнение. Редактирование скрипта, понятное дело, только руту доступно. Так реализует скрипты для администрирования системы. Какая-нибудь задача self-service. И в случае описанном в статье это будет как раз уязвимость повышения привилегий.
Незачем тут мудрить с пейлодом в [ ] или ( ) .
на безрыбье и рак рыба. Вы, видимо, никогда не взламывали никакие системы. С чем соглашусь — почти наверняка в системе будут более простые и более интересные уязвимости — ну, не знаю, слишком широкие права на конфигурационные файлы или скрипты в рутовом crontab, доступные для редактирования обычных пользователей
Есть сервер. На нем есть непривилегированные пользователи. Скрипт запускается либо со sticky bit/suid или чем-то подобным, либо прописан в sudo у пользователя на исполнение.
Это называется архитектор мудак. Можно уволнять. Запускать шелл скрипты через вебсервер это сверх извращение. Для выполнения задач от вебсервера где-то видел используют perl скрипт, но самое правильное пишется сервер с FIFO очередью(команды могут выполняться долго, вебсервер не может ждать выполнения, и должен быстро вернуть страницу на запрос), который будет принимать, валидировать и выполнять сообщения от вебсервера. bash это обычный язык сценариев, не надо молотком шурупы закручивать!
Запускать шелл скрипты через вебсервер это сверх извращение
это вы сами себе придумали ) Я ничего не говорил про веб-сервер.
Речь про некие оболочки для админских задач, возможно, интерактивных из консоли. Хотя сейчас — да, почти что угодно можно реализовать на веб-сервере на Flask'е, а дальше под капотом пускай будут exec() и прочие полезные и хорошие вызовы )
Речь про некие оболочки для админских задач, возможно, интерактивных из консоли.
С каких пор непревилегированные пользователи выполняют админские задачи?
Вам не кажется, что тут проблемы в архитектуре приложения, но никак не в шелл скрипте?
С каких пор непривилигированные пользователи выполняют админские задачи?
с того, что иногда это необходимо. Система прав линукса не разделяет пользователей на категории — грубо говоря есть рут, и есть все остальное. Конечно, есть система прав на файлах, есть дополнительные уровни вроде setfacl/getfacl, есть CAPs у приложений… Но по факту сделать простую вещь — дать пользователю привилегию на ХХХ, при этом не давая ему остальных полномочий и не переделывая настройки в еще половине системы — весьма затруднительно.
Как простой пример. Вот представьте себе — сервер. На нем крутится докер. В докере какая-то программа. Есть условный админ — у него полные права. И есть разраб. Ему нужно дать возможность обновлять приложение, перезапускать, может быть что-то еще. Но не более. Чтоб не дай Бог не заруинил систему.
Как будете решать? Одно из наивных решений — как раз засунуть это все в скрипт, не притаскивая какие-нибудь сложные штуки вроде https://www.portainer.io (у которых, между прочим, свои проблемы есть).
Как простой пример. Вот представьте себе — сервер. На нем крутится докер. В докере какая-то программа. Есть условный админ — у него полные права. И есть разраб. Ему нужно дать возможность обновлять приложение, перезапускать, может быть что-то еще. Но не более. Чтоб не дай Бог не заруинил систему.
Как будете решать?
docs.docker.com/engine/security/rootless
Не работает нормально )
Ну, и когда вообще возник этот вопрос рутлес даже в проекте не было. Вы можете поподкалывать меня, что я меняю условия вопроса на ходу, но нет, рутлес докер не принимается (как и Подман — который в базе тоже из-под пользователя не особо работает)
И ещё добавлю. Ну, Окей. Будет рутлес. Но это не позволит пользователю публиковать сервис на непривилегированных портах. И, напротив, даст слишком широкие права в том ключе, что пользователь сможет запустить любой недоваренный код. А речь шла в моем изначальном вопросе о закрытом (=ограниченном) перечне действий с конкретным контейнером или подмножеством контейнеров, запущенных на конкретном сервере
Не работает нормально )
Можно поподробнее? Возможно, я чего-то не знаю, но у меня несколько компонентов небольшого проектика уже полгода как крутятся в docker rootless в продакшне.
Если ходите на сервер по ssh то лучше без пароля и по ключу, это уже стандарт, верно? Разраб дает свой key.pub, вы прописываете его в на сервере, и перед ключем указываете ограничения или привилегии. В man sshd дивные 15 строк решат 90% проблем. Например даете рута на что-то.
Если ходите на сервер по ssh то лучше без пароля и по ключу, это уже стандарт, верно?
к делу не относится, но верно
Разраб дает свой key.pub, вы прописываете его в на сервере, и перед ключем указываете ограничения или привилегии.
точно так же можно навесить ограничения на юзера, причем тут ключ? :-)
Или имеется в виду сегрегировать разных девелоперов, ходящих под одним юзером? А зачем это допускать вообще, если у каждого может быть свой SSH юзер?
Не совсем понимаю в чём проблема. Это задокументированное поведение bash.Не совсем, ввиду:
$ bash --posix x.sh
Enter guess: a[$(date >&2)]+42
вторник, 18 мая 2021 г. 21:25:35 (MSK)
Correct
Хотя `man bash' описывает
--posix
Change the behavior of bash where the default operation differs
from the POSIX standard to match the standard (posix mode). See
SEE ALSO below for a reference to a document that details how
posix mode affects bash's behavior.
о которой говорят очень и очень мало
Да на каждом шагу слышно "не пиши на bash", ну и собственный опыт.
И если не валидировать ввод получается фигня
Все не завалидируешь (и это тупиковый путь). Тут в другом проблема — многие воспринимают bash/yoursh скрипты как язык программирования, а это не совсем так. Ну по факту ты программируешь команды, но делает это та же самая оболочка где ты водишь команды. Со всеми своими ньюансами типа разворачивание звездочки в список файлов в текущей директории и т.п.
Ну а про заключение в двойные кавычки переменной при сравнении кто только не говорил (говорят очень и очень мало, да. Я не слышал значит не говорят)
Да на каждом шагу слышно «не пиши на bash», ну и собственный опыт
Вот нужен скрипт в системе. Система имеет для этого инструмент. На чём ещё писать?
На питоне? Бесспорно, где-то он удобнее, но тянуть в систему виртуальную машину и сторонние библиотеки, повышая количество точек отказа — о какой безопасности тут вообще речь, не говоря уже о производительности? И ждать новых сюрпризов от авторов, которые в какой-то момент решат, что чёрный фон терминала оскорбляет чьи-то чувства и поэтому код на питоне в таком терминале больше работать не будет.
Согласен. Но тут надо оценивать перспективы. Баш — он, как оказывается, не везде одинаковый (мы это уже выяснили). А большие скрипты на нем трудно поддерживать.
К тому же Python тоже есть в практически любом линуксе, потому что, например, от него зависит пакетный менеджер yum. В убунту Python тоже в 90% случаев есть из коробки.
Как же у вас всё усложнено… bash… валидировать… без лыж в гамаке никак нельзя?
[: a[$(date: unexpected operator
Wrong
$ uname -srm
FreeBSD 13.0-RELEASE amd64
Когда мне нужно быстро что-то слепить, я буду делать это на sh, потому что он есть везде и я его знаю (потому что он есть везде). Эта самоподдерживающийся замкнутый на себя процесс.
Единственный способ достичь нирваны — постепенное улучшение языка sh.
Единственный способ достичь нирваны — постепенное улучшение языка sh.Сомневаюсь, что это можно сделать, не сломав обратную совместимость.
Вон в `bash' даже ключ специальный придумали `--posix' и что? И ничего, `bash --posix ./myscript' это пример исполняет во всей красе, а нормальный POSIX shell отвергает его.
Нормальная альтернатива — POSIX shell.В posix shell есть проблема с экранированием пробелов? Кроме этого, существуют и другие вопросы, как отсутствие протокола для взаимодействия программ(весь вывод в виде текста), довольно большая специфичность как синтаксиса, так и приёмов работы, например эмуляция хеш массивов, использование текстовых переменных вместо массивов(например, $PATH).
Вместо тонны статей, просто дайте людям ссылку на shellcheck и пусть им валидируют свои скрипты.
$ aptitude search shellcheck
p shellcheck - lint tool for shell scriptsЯ думаю подразумевалась вебформочка на https://www.shellcheck.net
А не утилита командной строки. Хотя тоже — aptitude? Серьезно? В банках? Там допотопный RHEL6, хорошо если 7. Но не везде ) Банки разные бывают :-)
Я думаю подразумевалась вебформочка на www.shellcheck.net
Это просто вебморда к тому же скрипту на Хаскеле
Там допотопный RHEL6
Ну не такой уж он и допотопный. Впрочем Хаскель есть и для RHEL5
КГ\АМ
Вам стоит изучить матчасть, перед тем как писать комментарии содержащие провокационную информацию для квалифицированного сообщества. Изучите ветку комментариев которую вы породили.
хороший совет. Это первый шаг. Но вообще shellcheck недостаточно. А лучше всего — вообще на шелле НИКОГДА и НИЧЕГО не писать. Та же проблема с тем, что у тебя Шелл работает только поверх кодов возврата и текстовых потоков. Никакой типизации, никаких юнит-тестов. Это хорошо работает только для ад-хок задач
Не понимаю, почему не писать простое
if [ "$num" -eq 42 ]./r.sh: строка 5: [: a[$(date >&2)]+42: ожидается целочисленное выражениеНужность башизма [[ имхо преувеличена.
После того как на работе решили все скрипты писать начиная с #!/bin/sh -eu и судя по тому, что полёт пока нормальный, тоже начинаю подозревать, что баш переоценён как скриптовый язык.
Без echo ${A%%.png}.jpg и echo item{1..10} не грустно?
$ sh -eu myscript
Enter guess: a[$(date >&2)]+42
myscript: line 3: a: unbound variable$ PATH=/usr/bin:/bin: sh -eu -o posix myscript
Enter guess: PATH[$(date >&2)]+42
среда, 19 мая 2021 г. 00:33:01 (MSK)
myscript: line 3: /usr/bin:/bin:: syntax error: operand expected (error token is "/usr/bin:/bin:")
WrongP.P.S.
Да! Можно ж и безошибочный вариант пользовательского ввода предложить:
$ sh -eu -o posix myscript
Enter guess: IFS[$(date >&2)]+42
среда, 19 мая 2021 г. 00:52:57 (MSK)
CorrectP.S.
А вот во FreeBSD, где /bin/sh реальный POSIX shell… Но это другая тема.
а в контейнерах любят нонче alpine, в котором sh aka ash… Поэтому минимальное рабочее подмножество для написания скриптов — это /bin/sh без всяких наворотов типа башизмов.
Я, наверное, плохо сформулировал мысль. Речь была о том, что мы приняли политику написания скриптов в едином стиле, который исключает такие бешенные вариации поведения. В частности, синтаксис [[ мы вообще не используем. Спасибо за Ваше исследование, оно подтверждает правильность нашего выбора!
Но, Вы правы, что любые отклонения от POSIX shell должны анализироваться, и не надо вот «Просто стоит помнить о том, что существуют двойные стандарты.», нужно что б их не было.
Честно говоря, я вижу в примере из статьи проблему не в соответствии стандарту, а в очень странном дизайне оператора [[. Он разворачивает переменную дважды, сначала из variable expansion $num, а потом то, что внутри — (command substitution $(...)). Обычно (при вызове команд) правила другие — переменные раскрываются один раз и потом разбиваются на слова (или нет, если в кавычках). Двойное раскрытие (применение command substitution к результатам variable expansion) — это сюрприз. Так не должно быть.
Кроме того, и в POSIX shell, скажем, в Bourne (Thomson) shell FreeBSD, арифметическая подстановка работает похожим образом, к примеру:
$ x=1+1 ; echo $x ; echo $(($x))
1+1
2
В bash безобидная с виду конструкция [[ $var -eq 42 ]] умеет выполнять и произвольный код