Специализирующаяся на компьютерной безопасности компания DefenseСode обратила (http://blog.defensecode.com/2014/06/back-to-future-unix-wild...) внимание на реальность эксплуатации особенностей обработки масок при выполнении утилит в командной строке. Суть проблемы в том, что при указании масок, таких как "*", осуществляется простая замена списка в командной строке, при которой имена файлов начинающиеся с символа "-" интерпретируются не как файлы, а как переданные утилите опции. Данное поведение до сих пор рассматривалось (http://seclists.org/fulldisclosure/2011/Sep/192) не как уязвимость, а как известная особенность командных интерпретаторов.Например, если запустить "rm *" и в текущей директории окажется файл с именем "-rf", то будет применена опция "rm -rf", что приведёт к удалению не только файлов, но и директорий. Другим примером может послужить создание файла с именем "--reference=.file.php", что при выполнении команды "chown nobody:nobody *.php" (или "chmod 000 *") приведёт к смене владельца не на пользователя nobody, а на владельца файла ".file.php" (или к смене прав на права файла ".file.php", которые могут быть -rwxrwxrwx). Если этот файл является символической ссылкой на /etc/shadow и команда выполнена под пользователем root, то смена владельца/прав будет произведена и для /etc/shadow.
Исследователи из DefenseСode считают, что такое поведение следует рассматривать как уязвимость, в доказательство чего опубликовали (http://www.defensecode.com/public/DefenseCode_Unix_WildCards...) технику атаки, которая может привести к выполнению кода при использовании утилиты tar. Если атакующий создаст файлы "--checkpoint=1" и "--checkpoint-action=exec=sh shell.sh", а администратор выполнит для архивирования типичную команду "tar cvvf archive.tar *", то после добавления одного файла в архив будет запущен скрипт shell.sh.
Аналогичного эффекта можно добиться при использовании утилиты rsync: создание файла "-e sh shell.c" и запуск "rsync -t *.c foo:src/" приведёт к выполнению скрипта "shell.c". Метод работает (https://dicesoft.net/projects/wildcard-code-execution-exploi...) и для утилиты scp: создание файла "-o ProxyCommand shell.sh %h %p" и выполнение "scp * user@example.org:/var/www/" приведёт к запуску скрипта shell.sh и передаче ему в качестве аргументов имени хоста и номера порта. В качестве средства для защиты от подобных атак рекомендуется использовать "--" или "./" перед маской, например, "rm -- *" или "rm ./*".
URL: http://blog.defensecode.com/2014/06/back-to-future-unix-wild...
Новость: http://www.opennet.ru/opennews/art.shtml?num=40100
OMG, незнал что такое возможно
Ещё вот так можно: http://linsovet.org.ua/content/chmod-x-chmod
# stat -c '%A' ./chmod
-rw-r--r--# /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ./chmod --help
Использование: ./chmod [КЛЮЧ]... РЕЖИМ[,РЕЖИМ]… ФАЙЛ
или: ./chmod [КЛЮЧ]… ВОСЬМ-РЕЖИМ ФАЙЛ…
или: ./chmod [КЛЮЧ]… --reference=ОФАЙЛ ФАЙЛ…
Смена РЕЖИМА доступа к указанным ФАЙЛАМ.
При задании --reference, установить режим
указанных ФАЙЛОВ как у ЭФАЙЛА.
> Использование: ./chmod [КЛЮЧ]... РЕЖИМ[,РЕЖИМ]… ФАЙЛРусский chmod. Бессмысленно и беспощадно.
бывало, ловил. :) оттуда у меня и замена - на A в скриптах :)
Не знал, что такое не возможно//fixed
> [leon@defensecode WILD]$ strace rm *
> execve("/bin/rm", ["rm", "DIR1", "DIR2", "DIR3", "file1.txt", "file2.txt",
> "file3.txt", "-rf"], [/* 25 vars */]) = 0
> ^- HEREВо FreeBSD, кстати, не сработает.
Как и многое другое:)
Раньше считал это недальновидностью и непродуманностью UI, а оно вон как оказалось.
>> [leon@defensecode WILD]$ strace rm *
>> execve("/bin/rm", ["rm", "DIR1", "DIR2", "DIR3", "file1.txt", "file2.txt",
>> "file3.txt", "-rf"], [/* 25 vars */]) = 0
>> ^- HERE
> Во FreeBSD, кстати, не сработает.Во FreeBSD в отличие от glibc несломанный POSIX getopt(3).
Так что передастся rm-у "-rf" как опция или как файларгумент будет зависеть от того,
на какое место она станет после раскрытия *.
Но в целом "проблема" глобальна.
нужно ещё после -rf добавить оидн пусть как минимум
Пусть - это ласковое название символа пробела?
> Пусть - это ласковое название символа пробела?Ну так "пустота" же.
забавно.
два минуса придумали как раз для этого, для разделения интерпретируемых аргументов и подставленных имён файлов
Всё равно это бага, broken by design по ихнему. Интерпретатор понятия не имеет о назначении аргументов. Правильное решение когда программа сама обрабатывает маски, а не когда приходится вбивать слеш или заворачивать маску в кавычки. И, кстате, в некоторых случаях (а у некоторых -- очень даже во многих) легко напороться на дофига файлов и упереться в ограничение длины командной строки.
для этого и придумали два минуса, всё что после них обрабатывается как имя файла, а реализовывать один и тот же алгоритм разбора масок в каждой программе достаточно глупо.
ага, C startup code в каждой программе вообще глупость, да?
идиотское сравнение
> ага, C startup code в каждой программеА в некоторых его может и не быть. Облом, правда? :)
> для этого и придумали два минуса, всё что после них обрабатывается как
> имя файла, а реализовывать один и тот же алгоритм разбора масок
> в каждой программе достаточно глупо.Вообще-то, для решения этой проблемы были придуманы библиотеки, в т.ч. и shared библиотеки. И ведь в libc подобный алгоритм не был бы лишним, между прочим.
> для этого и придумали два минусаА обрабатывать два минуса в каждой программе, это умно, ага.
> А обрабатывать два минуса в каждой программе, это умно, ага.man 3 getopt
>> А обрабатывать два минуса в каждой программе, это умно, ага.
> man 3 getoptcуровые джедаи не пользуются библиотеками. даже libc.
Работа с аргументной строкой как с монолитной raw строкой в принципе 'broken by design', случай с разворачиванием звёздочки только один из подобных негативных сайдэффектов. В нормальной архитектуре чанки аргументной строки должны быть теггированы.
Если говорить о linux'е, то ни о каких монолитных raw строках речи не идёт. В помощь вам: man 2 execve.
Затем, правда, мой склероз мне отказывает, и я уже не могу сказать, кто именно заполняет argv[] и envp[] для процесса -- libc или ядро, -- но даже если и libc, то всё равно речь идёт вовсе не о "монолитной raw" строке, но о argz/envz векторах, заботливо положенных ядром на стек. Что, вероятно, можно эксплуатировать, используя то, что символ '\0' имеет особое сакральное значение. Но, глядя на заголовок execve, признаемся себе, что вряд ли.
Так что случай с разворачиванием звёздочки -- это негативный сайдэффект какой-то другой проблемы, и вовсе не фиктивной проблемы каких-то там "монолитных raw-строк".
Товарищ явно имел в виду что-то типа Windows Shell, чтоб шаг влево-вправо - расстрел.
Расстрелом делать не обязательно, но метаинформация - вообще штука хорошая
Для чего хорошая? В каких случаях хорошая?Вы серьезно готовы отстаивать точку зрения о том что именно шелл - то самое место где имеет смысл жертвовать гибкостью ради прочего?
Тем более что пример-то - прямо перед глазами, Windows PowerShell же, в котором проще застрелиться (или, что чаще - написать скрипт прямо на С#) чем сделать что-то, чего разработчики не предусмотрели эксплицитно.
Сильно зависит от реализации, конечно, но в общем - Я бы предпочёл для любых случаев иметь формализованный вариант и текущий как фоллбек. Потому что одно дело - быстро наляпать одноразовый скрипт для известных данных, а другое - какие-то долго/часто используемые инструменты или программы со сложным выводом вроде ps.И, право, я не вижу ничего ужасного в том, чтобы отдавать вывод какого-нибудь PS в формате protocol buffers или аналогичном - с именованными и типизированными полями. И параметры командной строки иметь умные, со стандартно задаваемыми списками значений, без возни с кавычками и апострофами и так далее. А заодно - вместо sh/bash - что-нибудь хотя бы на уровне питона. Ну чтобы хоть арифметика нормальная была, переменные, контейнеры ключ-значение и т.д.
А PowerShell - это всего лищь паршивая реализация, и только. Майкрософт вообще угробила кучу хороших идей убогой релаизацией - хотя бы идею компонентной ОС вспомнить, когда у большинства майкрософтовских продуктов COM-интерфейсы дают все возможности гуя и даже большие - но при этом пользоваться этой мерзостью предельно неприятно. Тужа же - OLE.
как минимум шелл ты себе можешь заменить на что угодно. знаешь, он ведь не прибит гвоздями к ядру.более того: из этого своего шелла ты можешь вызывать другие программы, передавая им значения так, как хочешь. только свои, конечно, потому что остальные никто переписывать не станет. но можно сделать над ними обёртки, которые, зная параметры вызываемых программ, будут стараться обеспечивать какую-то безопасность и сервис.
Мне не шелл бы, а соглашение о формате. В идеале - поддержанная на уровне системы метаинформация для пайпов, чтобы реципиент мог узнать хоть что-то о получаемом потоке данных не полагаясь на его контент (который, разумеется, может быть каким угодно). К примеру, уметь устанавливать писателем и получать читателем mimetype или что-о подобное. Дальше - делать форк coreutils, умеющий это дело понимать.А шелл - это уже глазурь на торте, хотя я не могу понять, чего они до сих пор такие уродливые.
> Мне не шелл бы, а соглашение о формате.так в чём проблема-то? пишешь библиотеку сборки и парзинга твоего нового формата, пишешь шелл, который её использует — телемаркет! ну, и дальше усердно пишешь обёртки.
но всё это лишнее, на самом деле. по крайней мере, для консоли — лишнее.
А теперь расскажи, как мне сделать, чтобы можно было из любого процесса, как-либо оплучившего fd, узнать, в каком формате через него данные ждать. Ну, то есть можно в /tmp пытаться что-то вроде базы держать, но маразм же. А иначе - смысла не имеет, выдумывать способ детектирования - это нарываться на проблемы.Что до консоли - я вообще не уверен, что она должна оставаться в нынешнем виде. Зачем нужна текстовая консоль, если везде графические терминалы? А вот иметь не тупой поток байт, а структуру - команды, коды возврата и история их stdin/stdout/stderr по отдельности (и не забываем - этот вывод тоже структурирован, что позволяет, например, сделать разумный фолдинг), те самые шелл-паттерны a-la списки файлов, выбираемые в каком-то своём интерфейсе и отображаемые соответственно, и так далее - было бы куда как интереснее. Например, в половине случаев те же severity levels консольного лога было бы удобнее в консоли обрабатывать, а не в приложении, когда нагрузку лог создаёт малую, а просто вывод флудит. А так - надо - открыл топ-левел, глянул, что нужно, закрыл и дальше смотришь одним глазом на консоль.
> А теперь расскажи, как мне сделать, чтобы можно было из любого процесса,
> как-либо оплучившего fd, узнать, в каком формате через него данные
> ждать.1. уговорить автора использовать твою библиотеку для получения параметров.
2. написать очередную обёртку самому.> Что до консоли - я вообще не уверен, что она должна оставаться
> в нынешнем виде. Зачем нужна текстовая консоль, если везде графические терминалы?затем, что ничего мощнее и выразительней, при этом сравнимое по простоте использования, пока что не придумали.
задумайся над тем, что пиктографическое письмо вроде бы и красивей, и даже наглядней — но отчего-то не прижилось.
то, что ты предлагаешь, даёт усложнение концепции без явного выигрыша. подход никсов — «даём средства для построения механизмов». описываемый тобой подход: «вот вам готовые механизмы, кто недоволен — сам себе дурак.» у нас уже есть такая компания, сейчас они systemd занимаются.
Не, я просто хочу более мощные механизмы. В частности - мне не нравится, что куча инфы безвозвратно теряется при вываливании в байтовый поток, а я потом об это бьюсь, пытаясь понять, где там разделяются поля, где невесть что в имени файла, где формат поменялся потому что локаль не та и где я поставил три, а не четыре бэкслэша и поэтому экранирование кривое. Я, право же, не вижу, чем пачка инструментов, умеющих обрабатывать структуру, хуже такой же пачки, обрабатывающей текст, в который эту же структуру упростили. При том, что если нужен тупой текст, а получил структуру - это делается тривиально, а вот наоборот - шиш.Мощность и выразительность при этом ни разу не теряются. Простота - сами тулзы (там, где разбор формата) получаются чуть сложнее, зато избавляем пользователя от кучи рутинных проблем и даём новые возможности. А как и насколько использовать эти возможности собственно в шелле/терминале - вот здесь уже дело хозяйское. Хоть вываливай как раньше, хоть делай возможность свертки вывода каждой команды и красивые диалоги выбора файлов - на усмотрение.
хуже в том, что без специнструментов с этими структурами уже ничего не сделаешь. а текст можно руками напечатать и глазами прочитать. поэтому текст — универсален, хоть и немного неудобен временами. а спецструктуры — нет.впрочем, это опыт, который приходит только после граблей. я, например, больше не делаю бинарных протоколов обмена. ибо граблями по лбу — больно.
в языках программирования это давно решено через Object.toString() и new Object(string)
не придумывайте граблей там где их нетдико люто бешено не хватает нормально представления данных в консоли
на работе занимаюсь программированием и башобвязкой своих сервисов
хорошо, что мы никогда не столкнёмся в реале, товарищ Беспроблемный.
> Майкрософт вообще
> угробила кучу хороших идейПослушайте Изя, он нас еще и коммерции учить будет ;)
> И, право, я не вижу ничего ужасного в том, чтобы отдавать вывод
> какого-нибудь PS в формате protocol buffers или аналогичном - с именованными
> и типизированными полями.Теперь смотрим в сторону XML-RPC, и долго думаем почему он таки не взлетел.
> А PowerShell - это всего лищь паршивая реализация, и только.
Нет, не только.
> Майкрософт вообще угробила кучу хороших идей убогой релаизацией - хотя бы идею компонентной
> ОС вспомнить, когда у большинства майкрософтовских продуктов COM-интерфейсы дают все возможности
> гуя и даже большие - но при этом пользоваться этой мерзостью предельно неприятно.Только если не понимать как она работает и пытаться её использовать через десяток кривых прокладок типа С++ с MFC.
> Только если не понимать как она работает и пытаться её использовать через
> десяток кривых прокладок типа С++ с MFC.да даже если понимать — это ужас. интерфейсы, которые спрашивают интерфейсы у интерфейсов, и всё это надо руками рефкаунтить, и… и ну его нафиг, такой хлебушек.
Он много почему не взлетел. И потому что нефиг совать RPC туда, где должны быть сообщения, и потому что сам формат ужасен и в принципе не пригоден для быстрого обмена, особенно бинарными данными. И вообще XML-RPC - это не о том. Я не предлагаю на всё наклепать жесткие прототипы, а просто если есть в выводе поля - их аннотировать и разделять. То есть прилетает ридеру что-то - он в глаза может формата не знать, но если ему нужно поле "foo" - он смотрит в заголовок, видит, как это поле выгрести из структуры и выгребает. Ничего из возможностей того же grep и прочих утилит это не отменяет, просто избавляет от игр с разделителями, экранированием и тому подобным.
И с COM - та же проблема, что с XML-RPC - чересчур переусложнено, рефкаунтинг, RPC там, где сервер может и не ответить, и так далее.
> А PowerShell - это всего лищь паршивая реализация, и только.Нет. Это именно дурная идея. PowerShell стоит на базе .NET'а, система типов которого крайне устарела, и многое не поддерживает. Чтобы заменить bash по удобству, нужно иметь что-то по мощности системы типов не уступающее Хаскеллю. Да и по другим параметрам bash на объектно-ориентированный язык не заменяется.
> Товарищ явно имел в виду что-то типа Windows Shell, чтоб шаг влево-вправо - расстрел.Пусть он им попробует попользоваться. Интересно через сколько часов (или дней) он застрелится.
> Товарищ явно имел в виду что-то типа Windows Shell, чтоб шаг влево-вправо - расстрел.товарищ имел явно в виду только то что написал, а именно речь шла о протоколе передачи аргументной строки. а не о форме реализации ui. PS в этом срезе ничего принципально не меняет.
В реализации к execve() кроме массива строк с аргументами добавляется ещё один массив с тегами, каждый тег чиселка чего-то означающая. По умолчанию все теги RAW, тогда программа должна интерпретировать их как делала это раньше. Кромe RAW могут быть другие хинты типа PATH, OPT, VALUE мб ещё несколько хинтов, много их не нужно. Вот и вся технология теггирования, полностью совместима со старым методом передачи аргументов и даёт возможность новому ПО не натыкаться на типичные проблемы. Это уже ответ на вопрос ниже как бы не поломать гибкость.
опять эти улучшатели… всем лёнины лавры покоя не дают.
И получится у вас XML-RPC.
Это именно то чего не хватало командной строке, да.
В каком месте это хоть как-то похоже на xml-rpc? Тут, конечно, понятно что ты херню несёшь составленную из незнакомых слов, но может потрудишься хотя бы в википедию сходить и сделать сравнение.
если говорить о linux и юниксах, где значительная часть операций идёт через шел, то строки именно монолитные и в execve попадают порезанными примерно по пробелам шеллом. Покрути своей невнимательнйо мордочкой вверх и узри что речь идёт о sh.И эта порезка на части для execve() даже при правильном использовании без теггирования мало чем помогает. Как правильно выше заметили, вызывающая сторона ничего не знает о семантике аргументов (sh или ей аналогичный генератор строк), либо легко ошибиться с порядком и кол-вом - нет никаких способов защиты от таких распрастранённых ошибок.
> нет никаких способов защиты от таких распрастранённых ошибок.это у говнокодеров нет. у остальных нормальных людей есть конвенции по интерпретации параметров и волшебный параметр «--».
тэгирование — это, конечно, стильно, модно и всё такое. а как тэгировать параметр «truiwghiuwhg»? это у меня кот пробежал? или это я файл такой создать хочу? или у меня уже есть такой файл, но я не его имел в виду, а вовсе даже выругался? угу, привет, очередные костыли для задания типов аргументов, экраны и прочая механика, которая уже и так есть. только на этот раз — с идиосткими усложнениями и тотальным ломанием интерфейсов, как любят хипстеры.
> это у говнокодеров нет. у остальных нормальных людей есть конвенции по интерпретации параметров и волшебный параметр «--».обезьяна, ты что такая тупая? '--' всего лишь частный костылик который даже в случае с передачей путей подходит не для каждой команды. И конвенций нигде никаких нет.
> тэгирование — это, конечно, стильно, модно и всё такое. а как тэгировать параметр «truiwghiuwhg»? это у меня кот пробежал? или это я файл такой создать хочу? или у меня уже есть такой файл, но я не его имел в виду, а вовсе даже выругался?
ну ты то со своей головой дружишь или совсем никак? Если передаёшь какой-то аргумент программе, то должен знать что передаёшь. Хотя бы должен занть что из передаваемого ключи, а что нет. Для хинтов этого хватит.
Если передаёшь аргумент из другой программы, например через execve(), то всегда знаешь как правильно расставить хинты. sh всегда может правильно расставить хинт для подстановки звёздочек и глоббинга. Придумать ui, который сможет догадываться где опции и где нет тоже можно.
Программы с далеко идущими сайдэффектами в свою очередь (rm, например) могут отказываться что-то делать с непроставленными тегами.
> угу, привет, очередные костыли для задания типов аргументов, экраны и прочая механика, которая уже и так есть. только на этот раз — с идиосткими усложнениями и тотальным ломанием интерфейсов, как любят хипстеры.
это всего лишь твои фантазии, интерфейс не ломается. Я честно не понимаю, почему всякое ламерьё постоянно додумывает решение в каком-то совершенно маразматическом виде из всех возможных
хм, а раньше ты таким идиотом не был. или маскировался хорошо? in either case: fuck you.
>> это у говнокодеров нет. у остальных нормальных людей есть конвенции по интерпретации параметров и волшебный параметр «--».
> обезьяна, ты что такая тупая? '--' всего лишь частный костылик который даже
> в случае с передачей путей подходит не для каждой команды.Если разработчик вменяемый, он использует getopt(3) или getopt_long(3).
В обоих случаях наличие "--" гарантировано.
В случае getopt(3) гарантировано по POSIX.
точно прочитал мой коммент прежде чем отвечать?
> если говорить о linux и юниксах, где значительная часть операций идёт через
> шел, то строки именно монолитные и в execve попадают порезанными примерно
> по пробелам шеллом. Покрути своей невнимательнйо мордочкой вверх и узри что
> речь идёт о sh.
> И эта порезка на части для execve() даже при правильном использовании без
> теггирования мало чем помогает. Как правильно выше заметили, вызывающая сторона ничего
> не знает о семантике аргументов (sh или ей аналогичный генератор строк),
> либо легко ошибиться с порядком и кол-вом - нет никаких способов
> защиты от таких распрастранённых ошибок.Вызывающая сторона как раз должна знать. И эта сторона - не sh. Однако sh делает некоторое сложнопредсказуемое для некоторых вызывающих сторон преобразование...
Так это вызывающие стороны мануал по шеллу не читали, поэтому трудно предсказывать
> если говорить о linux и юниксах, где значительная часть операций идёт через
> шел, то строки именно монолитные и в execve попадают порезанными примерно
> по пробелам шеллом. Покрути своей невнимательнйо мордочкой вверх и узри что
> речь идёт о sh.Простите, я полагаю порезку "примерно по пробелам" неизбежной. Можно конечно заменить "примерно пробелы" "примерно запятыми", или "примерно точками с запятой", но, по-моему, ничего от этого коренным образом не изменится: процесс парсинга скрипта/командной строки неизбежен. Будем ли мы дополнять его тегированием, или не будем, но резать строку на части всё равно придётся, потому что я вбиваю команды разбивая отдельные части пробелами.
> И эта порезка на части для execve() даже при правильном использовании без теггирования
> мало чем помогает.Расскажите мне, как вы планируете тегировать поток черектеров проходящий через pipe. Ведь список аргументов может генерироваться сторонним процессом, и передаваться в качестве аргументов целевому. Можно не тегировать pipe, можно просто договориться, что через пайп можно передавать лишь аргументы отличные от опций. Но это тоже ведь не совсем удачно, а если я дополняю в стороннем процессе каждый аргумент опцией-"тегом", поясняющей что это за аргумент? Ну, например, генерирую последовательность: --ifile=a --ofile=b --ifile=c --ofile=d...
Отмечу, что теги придётся уметь хранить и в файле, потому, что создавая список файлов/опций для вызова программы (б.м. многократного), бывает удобно складывать список опций/файлов в файлик, по одной на строке. Отмечу, что механизм тегирования будет необходим в виде самостоятельного механизма, который я, как пользователь командной строки, должен иметь возможность использовать тогда, когда мне это удобно, потому что случается собирать аргументы из данных имеющих строковый или числовой тип. То есть из строк и чисел я хочу получать, по-желанию, имя файла или просто аргумент, так как я захочу, а не так как решит "эвристика" программы, которая будет заниматься тегированием.
В общем я к тому клоню, что если начать тегировать, то кончится это неуёмным использованием xml'я во все щели. Быть может, разработчики-таки придумают свой синтаксис, покомпактнее xml'я, но, боюсь, сильно лучше от этого не станет. От читабельности вывода программ придётся отказаться точно. Может это и к лучшему, но до тех пор, пока вы бестолково рассуждаете о том, как бы было хорошо, если бы кто-нибудь сделал хорошо, оценить ваши идеи мы не можем. Чтобы донести свои идеи до окружающих, надо писать код, вы ведь в курсе этого?
И, между прочим, чтобы решить описанную выше проблему, я могу предложить вам следующий скрипт в cron'е: find / -name '-*' -exec rm -rf -- {} \; Решение половинчатое, правильнее было бы на уровне vfs запретить создание файлов начинающихся с -. Но это уже для тех, кому больше всех надо. Отмечу что такое решение, по сравнению с вашим существенно проще и убивает проблему на корню, а не переносит её в другую плоскость. Создаётся, правда, второстепенная проблема -- невозможность иметь в файловой системе файлы начинающиеся с '-', но это не столь критично, по-моему: мне не приходилось сталкиваться с файлами, чьё имя начиналось бы с -.
> кончится это неуёмным использованием xml'я во все щелиСейчас вам объяснят что раз угловых скобочек для тэгов не предлагалось в исходном сообщении, то подобные аналогии неуместны. И в википедию отправят.
> Будем ли мы дополнять его тегированием, или не будем, но резать строку на части всё равно придётся, потому что я вбиваю команды разбивая отдельные части пробелами.Ты ничего не разбиваешь пробелами в командной строке, это фикция в твоей голове. Даёшь одну монолитную строчку интерпретатору который решает как её бить на части. Обычно твоя интуитивная фикция совпадает с тем, что делает (ba)sh интерпретатор, но не всегда.
Снижение расхождения между интуитивной интерпретацией человеком входных данных с фактическими это задача UI и его возможности снижения ошибок полностью ограниченны сверху протоколом передачи аргументов в программу. Выше речь идёт о последнем, т.е. о протоколе, а не о принципах устройства твой оболочки.
Немного отхотя от темы замечу, что у шелла есть достаточно данных для анализа вводимой строки и теггирования её частей. Например, шелл всегда знает что является результатот глоббинга, знает через autocomplete что ожидается в какой-то позиции - через свою же подстановку путей или через вспомогательный скрипт, который делает некий синтаксический разбор и уже имеет теггированные части.
Всем срать что ты там делаешь у себя в командной строчке. (ba)sh используется для автоматизации различных процессов и большая часть проблем возникает именно здесь, а не у тебя в ручном режиме. Оснвная задача теггированя это дать возможность защиты от ошибок в автоматике.
> Расскажите мне, как вы планируете тегировать поток черектеров проходящий через pipe. Ведь список аргументов может генерироваться сторонним процессом, и передаваться в качестве аргументов целевому.
Я то тут причём? Мне лично до одного места как ты будешь решать эту проблему. Каждый делает всё в меру своего идиотизма. Даже сейчас так никто не делает если хоть как-то обеспокоен проблемами безопасности. В процесс переадются какие-то структруированные, либо скалярные тривиальные, данные на основе которых уже происходит генерация опций.
В очередной раз попробую заметить, теггирование идёт на уровне протокола передачи аргументов процессу. заколебали тупить.
> Отмечу, что теги придётся уметь хранить и в файле, потому, что создавая список файлов/опций для вызова программы (б.м. многократного), бывает удобно складывать список опций/файлов в файлик, по одной на строке.
Аналогично, фантазии гогнокодера нет предела. Нормальные люди в файлах хранят структруированные данные на основне которых можно генерировать аргументы.
> я, как пользователь командной строки, должен иметь возможность использовать тогда, когда мне это удобно, потому что случается собирать аргументы из данных имеющих строковый или числовой тип.
Уже выше писал как это работает. Теги это хинты назначаения частей строки, не знаю почему вдруг у вас голове они стали типами. Легаси код, или в случае невозможности проставить тег, ставит неопределённый тег RAW.
Например
rm -rf some_path
в теггированном виде будет как
[ ('-rf', OPT), ('some_path', RAW)]
или
[ ('-rf', OPT), ('some_path', VALUE)]
или, если bash сделал свой комплит
[ ('-rf', OPT), ('some_path', PATH)]или в легаси режиме
[ ('-rf', RAW), ('some_path', RAW)]
> В общем я к тому клоню, что если начать тегировать, то кончится это неуёмным использованием xml'я во все щели. Быть может, разработчики-таки придумают свой синтаксис, покомпактнее xml'я, но, боюсь, сильно лучше от этого не станет.
у вас в голове всё смешалось в одну кучу. Прежде чем рассуждать нужно разобраться где есть что.
> И, между прочим, чтобы решить описанную выше проблему, я могу предложить вам следующий скрипт
это не решение, это последние беспомощные вопли утопающего.
> Немного отхотя от темы замечу, что у шелла есть достаточно данных для
> анализа вводимой строки и теггирования её частей. Например, шелл всегда знает
> что является результатот глоббинга, знает через autocomplete что ожидается в какой-то
> позиции - через свою же подстановку путей или через вспомогательный скрипт,
> который делает некий синтаксический разбор и уже имеет теггированные части.
> Всем срать что ты там делаешь у себя в командной строчке. (ba)sh
> используется для автоматизации различных процессов и большая часть проблем возникает именно
> здесь, а не у тебя в ручном режиме. Оснвная задача теггированя
> это дать возможность защиты от ошибок в автоматике.ммм...
> знает через autocomplete
> большая часть проблем возникает именно здесь, а не в ручном режиме1. Как это связано между собой?
2. Вы не думали о том, чтобы заменить для себя sh на что-нибудь другое. На python/ruby/php... На что-нибудь, что позволит вам при написании автоматизирующих скриптов, использовать более удачный интерфейс, который сможет исправлять недостатки? По-моему, это было бы правильно, ведь sh, всё же, не зря сокращение от shell -- это, в первую очередь, интерактивная командная строка.>> Расскажите мне, как вы планируете тегировать поток черектеров проходящий через pipe. Ведь список аргументов может генерироваться сторонним процессом, и передаваться в качестве аргументов целевому.
> Я то тут причём? Мне лично до одного места как ты будешь
> решать эту проблему. Каждый делает всё в меру своего идиотизма.Тогда поясните цели, которыми вы руководствуетесь, выступая здесь.
>> Отмечу, что теги придётся уметь хранить и в файле, потому, что создавая список файлов/опций для вызова программы (б.м. многократного), бывает удобно складывать список опций/файлов в файлик, по одной на строке.
> Аналогично, фантазии гогнокодера нет предела. Нормальные люди в файлах хранят структруированные
> данные на основне которых можно генерировать аргументы.Этим я занимаюсь иногда, но не тогда, когда решаю задачу, которую надо решить *однократно*. Возиться со структурированными данными, писать программы и комплексы программ для *однократной* задачи -- это идиотизм по-определению, поскольку *однократную* задачу быстрее решить вручную, чем через полный цикл разработки программы.
>> я, как пользователь командной строки, должен иметь возможность использовать тогда, когда мне это удобно, потому что случается собирать аргументы из данных имеющих строковый или числовой тип.
> Уже выше писал как это работает. Теги это хинты назначаения частей строки,
> не знаю почему вдруг у вас голове они стали типами.Потому что "тип" -- это очень удобное понятие из программирования, на которое красивым образом ложатся ваши "хинты", и позволяют разговаривать в привычных терминах, не изобретая велосипеда.
> Легаси код, или в случае невозможности проставить тег, ставит неопределённый тег RAW.
Это понятно. Но было бы неплохо, если бы хотя бы что-нибудь гарантированно имело бы тег, отличный от RAW. Например, чтобы опции команды, гарантированно имели бы тег OPT. Иначе какой смысл во всём этом тегировании?
>> В общем я к тому клоню, что если начать тегировать, то кончится это неуёмным использованием xml'я во все щели. Быть может, разработчики-таки придумают свой синтаксис, покомпактнее xml'я, но, боюсь, сильно лучше от этого не станет.
> у вас в голове всё смешалось в одну кучу. Прежде чем рассуждать
> нужно разобраться где есть что.Несмотря на это ваше заявление, я всё же остаюсь при мнении, что вы не представляете себе проблему во всей её сложности. Вы понимаете, что для решения вашей проблемы, придётся заталкивать в язык шелла типизацию? То есть, переменные типа RAW, хранящие строки неопределённого назначения, переменные типа OPT, в которых идёт накопление опций для команды, которая будет запущена ниже. Заодно уж тогда, придётся завести переменные типа INT, и пр, дабы получив себе геморрой связанный с типизацией, иметь возможность извлечь из него максимум удобств. Опять же возникает вопрос: может вы используете не тот инструмент, для решения задач? Может на самом деле, взять python и написать в нём целый API заменяющий вызов system, который будет реализовывать эти самые типы данных, и по типам раскидывать опции и не-опции в командной строке так, чтобы запускаемая программа не путалась бы в соплях?
>> И, между прочим, чтобы решить описанную выше проблему, я могу предложить вам следующий скрипт
> это не решение, это последние беспомощные вопли утопающего.Обоснуйте.
Проблема в том, чтобы получить с правильной архитектурой ту же простоту... А так - согласен, парсинг текста - хороший фоллбек, но в большинстве случаев что-то более структурированное было бы неплохо иметь.
> И, кстате, в некоторых случаях (а у некоторых -- очень даже
> во многих) легко напороться на дофига файлов и упереться в ограничение
> длины командной строки.тридцать два килобайта. демоны, ЧТО можно делать с командной строкой, чтобы насрать туда тридцать два килобайта? точнее, каким дауном надо быть, чтобы развести у себя на технике такую помойку, которая раскроется на тридцать два килобайта?
ну во-первых не 32кб, реально можно столько использовать, на сколько памяти хватит. это вполне удобным бывает (чисто практически, а то что изначально механизм не предназначен был для больших объемов - так это эстетство уже).
реально это зависит от многих факторов, включая то, какой shell используется. на современных GNU/Linux с bash 32 килобайта точно пролазит, поэтому я взял это как минимум.
лимит - четверть максимального размера стека (RLIMIT_STACK), гарантируется не менее 128кб, по дефолту мне везде попадалось 2мб (макс. память, занятая аргументами execve, включая env). но это искуственное ограничение, в баше достаточно сделать ulimit -s unlimited, и пролезет столько, сколько памяти хватит. и сами данные не в стеке находятся (ограничение на аргументы ставится для того, чтобы обеспечить выделение памяти под стек).
про shell тактично не заметил?впрочем, я старпёр, предпочитаю ограничиваться 32kb.
так shell сам не ограничивает длину, ограничивает ядро.
и если уж старперствовать по-полной, то лучше ограничиться 4кб :)
> так shell сам не ограничивает длинуlolwut?! O_O
> и сами данные не в стеке находятсяони находятся в стеке. Точнее вначале куска памяти, конец которого потом превращается в стек. С точки зрения дяра это всё стек.
это "broken by design" обсуждается с конца 80-х и есть антидоты.плотно эти ребята занимаются безопасностью, если только открыли это для себя.
> Правильное решение когда программа сама обрабатывает маскиНу, т.е. как когда-то в DOS.
>> Правильное решение когда программа сама обрабатывает маски
> Ну, т.е. как когда-то в DOS.и в винде до сих пор.
конечно, забудьте про расширеные глобы, забудьте про регулярные выражения, ведь теперь этим занимается не шелл, а прикладной софт. каждая софтина в меру своей забагованности и неленивости её автора.
дальше они предложат запретить подстановку переменных в командных строках, а то и это тоже небезопасно: пусть каждая софтина сама как-нибудь это делает. правда, у софтины нет доступа к внутренним переменным шелла, но они и для этого какой-нибудь костыль выдумают, ведь придумывать костыли вместо того, чтобы включить мозг и прочесть документацию — это так увлекательно!
> Например, если запустить "rm *" и в текущей директории окажется файл с именем "-rf"Ололо...
tar cf archive.tar *это же тар-бомба, которая крайне редко где применяется (а там, где применяется, уже один раз поймал и попортил себе систему :).
обычно tar cf archive.tar archive, чтобы потом удобно распаковывать было.
Никогда не указываю «*» в таких командах. Во-первых не цепляет файлы «.*», во-вторых известно, что это ненадёжно (и небезопасно). Всегда тупо указываю путь к директории (и если это CWD, то тогда тупо «.»).
> tar cf archive.tar *Знаешь, то что он тебе разъе... систему - к лучшему. Научишься вызывать программы нормально, наконец.
угу, а еще ./* разворачивается в ./-cheto-tam, то есть высосали из пальца проблему rm -rf *, времен 10-ти летней давности; а еще я читал историю в которой один мальчик набрал по приколу rm -rf * в корневой директории, мама позвола его обедать, а когда он вернулся, то нажал интер, чтобы разбудить комп и все убил;Этим исследователям безопасности делать похоже нехер, если уж кому-то открылась консоль рута, то этот кто-то обязан отдавать себе отчет в каждом действии, иначе есть винда которая или переспросит, или тупо не даст совершить ошибку. А то вырастили поколение кликоманов, которые долбят по кнопкам не думая и не глядя, а вотом вопят на форумах, что система гавно раз не работает, а ведь они всего лишь случайно файлик удалили.
> он вернулся, то нажал интер, чтобы разбудить комп и все убил;А почему не <CTRL>+<ALT>+<DEL>?
mv -t /blahblah -- *в чём проблема-то?
всегда так делаю.. и всегда делал раньше...
стоило ради этого писать новость?
вы ещё написали бы новость о том типа "О БОЖЕ, ЕСЛИ НЕ ЗАЭКРАНИРОВАТь В PHP HTML-ВЫВОД ЗНАЧЕНИЯ ПЕРЕМЕННОЙ ТО ПОЛУЧИТСЯ XSS!!"
ну детский сад же!
# P.S.: а по теме говоря -- всё идёт из-за непонимания того кто именно обрабатывает этот <*> (его обрабатывает BASH, но кто-то может подумать что это аргумент для mv, по аналогии с Microsoft Windows cmd.exe) .
> стоило ради этого писать новость?сугубо имхо, но, думаю, новость неспроста. где-то в недрах redhat планируется защита от таких "уязвимостей". например, перевод всех linux-утилит в стиль а-ля msdos, когда все маски обрабатываются не шеллом перед передачей команде, а самой командой. или вообще, systemd сочли законченным а поттернига занять нечем, и теперь он будет писать замену шеллу, в стиле PowerShell, с защитой от экранирования и пр.
по сути, аналогия с php на 100% верна.
Там всё куда интересней.
https://lwn.net/Articles/602579
> Там всё куда интересней.
> https://lwn.net/Articles/602579когда же он уже уйдёт пилить свой kerneld-то?
Одна из главных проблем с Леннартом - в том что все постоянно недооценивают уровень его притязаний.Он пойдет пилить только _meta_kerneld.
> Одна из главных проблем с Леннартом - в том что все постоянно
> недооценивают уровень его притязаний.
> Он пойдет пилить только _meta_kerneld.чёрт, да хоть universed, лишь бы побыстрее и подальше…
Дет.сад для того, кто успел перелопатить гору документации и протоптаться по граблям.
До сих пор ньюбов тыкают в маны, не обладающие, между прочим, выражаясь на математический манер, ни свойством полноты, ни свойством связности. Редких приличных ресурсов типа xgu явно недостаточно для формирования системного мышления.ЧСХ, я тоже начинал с подобных ляпов. Причём, перелопачивание инета зачастую помогает формированию бажного мировоззрения. Чего стоит "#!/usr/bin/env python" в скриптах, потенциально вызываемых из крона (с вычищенным окружением).
> Чего стоит "#!/usr/bin/env python"вот этого достаточно, в принципе.
Знаешь, если выбирать между шеллом и питоном - то, пожалуй, питон всё же получше. Хоть инструменты приличные есть.
а зачем ограничивать выбор только ними двумя?
Хм, логично. Хотя даже в питонине именно для "клея" между вызовами внешнего софта слишком много синтаксиса. Вот одно время был для перла модуль, который пытался все не найденные функции разрешать в вызовы system - примерно такое в питон бы надо. Но там думать и думать, чтобы сделать всё аккуратно.
> Специализирующаяся на компьютерной безопасности компания DefenseСodeтак вот где работает КЭП.
> ... и команда выполнена под пользователем rootЧо, опять рута надо?!
>> ... и команда выполнена под пользователем root
> Чо, опять рута надо?!Чтобы запустить бота под твоей учёткой рут нинужно.
> Чтобы запустить бота под твоей учёткой рут нинужно.А можно мне копию бота "pavlinux"? Он такой клевый :).
Вы еще один ненужный кэп?
Антивирус попова легко отлавливает таких ботов. Так что это неэффективно, кэп. Я могу написать такой анти вирус, если у вас болит.
А вот нас посетил бот Попoва :).
Проблема из за того как аргументы обрабатывает сам getopt.h и то как они подаются в программу особенно если смешивать с getopt_long. Так как иногда не обязательно передавать полное имя аргумента чтобы он был воспринять программой
> "...как аргументы обрабатывает сам getopt.h"Красноглазик, getopt.h ничего не обрабатывает. Даже если смотреть на исходники :)
На самом деле такие атаки вполне применимы на серверах хостинговых компаний. Там очень много скриптов автоматизации. Например такая частая штука как перенос аккаунта с сервера на сервер. Использование chown/chmod/rsync при таких операциях обычное дело и легко можно со стороны юзера инициировать атаку.Поэтому аргумент, что админу нужно смотреть и думать перед выполнением каждой команды, не состоятелен. Не зная о таких методах атак легко напороться.
Пля, опять не работает. (Debian 6 LTS)
/etc/ssh/sshd_config: line 102: Bad configuration option: ProxyCommand
> На самом деле такие атаки вполне применимы на серверах хостинговых компаний. Там
> очень много скриптов автоматизации. Например такая частая штука как перенос аккаунта
> с сервера на сервер. Использование chown/chmod/rsync при таких операциях обычное дело
> и легко можно со стороны юзера инициировать атаку.
> Поэтому аргумент, что админу нужно смотреть и думать перед выполнением каждой команды,
> не состоятелен. Не зная о таких методах атак легко напороться.От админа-идиота не спасёт ничего. И не надо портить систему в глазах нормальных админов потому, что админу-идиоту что-то не нравится.
если там админы — дауны, то описаное в новости будет самой маленькой и самой неинтересной из вороха наличествующих там проблем.
Как от этого защититься?
> Как от этого защититься?никого на сервер не пускать
> Как от этого защититься?купить где-нибудь рабочий мозг. или убить себя, это лучше и надёжней.
> Как от этого защититься?не использовать маски в шелл-скриптах (а там где нужно через командную строку передавать программе списки файлов - использовать для запуска например find ... -print0|xargs -r0 ..., чтобы ситуации с левыми символами в именах обрабатывались явным образом).
а при интерактивной работе перед запуском команды маски удобно заменять на конкретные списки (в разных шеллах по-разному, но функция стандартная).
Здрасьте, не рассматривалось. Они тоже вчера родившиеся убунтушники?Оригинал текста на http://docs.altlinux.org/archive/2.2/master/devel-html/ch03.... датируется примерно 2001 или 2002 годом, самое позднее.
> Здрасьте, не рассматривалось. Они тоже вчера родившиеся убунтушники?
> Оригинал текста на http://docs.altlinux.org/archive/2.2/master/devel-html/ch03....
> датируется примерно 2001 или 2002 годом, самое позднее.Миш, через несколько лет жди новость: "британские учёные обнаружили, что если открыть окно с эмулятором терминала, то А-А-А-А-А СТРАШНО ТУТ ЖЕ МОЖНО ВСЁ СНЕСТИ СЕВ ПОПОЙ НА КЛАВИАТУРУ!!!".
Ну или что-то в этом духе.
В общем, береги свой моск, с годами он будет цениться всё больше отнюдь не из-за антикварности. :)
> Миш, через несколько лет жди новость: "британские учёные обнаружили, что если открыть
> окно с эмулятором терминала, то А-А-А-А-А СТРАШНО ТУТ ЖЕ МОЖНО ВСЁ
> СНЕСТИ СЕВ ПОПОЙ НА КЛАВИАТУРУ!!!".Попой то ладно. Но работа со строкой параметров в интерпретаторах, действительно, безальтернативно опасна: нет выбора между сложным, но безопасным, или простым, но опасным. Эту особенность никак ни обойти, ни нивелировать невозможно. Увы.
Да. Эти чудеги могли-бы "Advanced Bash-Scripting Guide" почитать, разделы 3 и 9.1.
А вот представьте на секунду, что не только вы знаете об этом гиде. Более того, представьте, что баш не единственный интерпретатор на свете.
О, УЖАС.1. man "--"
2. Реальные перцы не используют "*".
/thread
// b.
молодцы, чо. они, наконец, начали читать unix haters handbook, видимо. там их ещё много чудных открытий поджидает, ждём ещё пачку Ломающих Новостей.
Сей факт известен всем, кто хоть немного писал скрипты для bash-а. Проблема в том, что редко в каком языке вообще работа с вводом/вывод лишена такой же уязвимости.