Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В UNIX архивы, скачанные из недоверенных источников, не только автоматически получают право на выполнение, но и автоматически исполняются?
Ну вот ты выкачиваешь foo.tar.gz. Распаковываешь. Заходишь внутрь. А там лежит файл с именем ls, правами 0755 и таким вот содержимым:
#!/bin/sh
rm -rf $HOME
А ты, такой, говоришь ls стоя в этой внутренней директории, вынутой из архива. Ну, чтобы список файлов посмотреть. А потом уже всякое такое говоришь, уже не компьютеру, а ртом, чего я даже воображать не буду, чего говоришь.
Здравствуйте, B0FEE664, Вы писали:
BFE>Как вы, параноики, от этого защищаетесь?
Параноика вызывали? Легковесными контейнерами. Точнее, там от контейнеров только пространства имен (namespaces), файловая система не виртуализируется.
Прелюдия:
В результате мы получаем небольшую изолированную среду, которая видит только часть системы и имеет свой домашний каталог (снаружи все файлы в ~/tmp/foo видны). А дальше стандартные
tar zxf foo.tar.gz
cd foo
bash configure
make -j11
Если оно что-то и удалит, то только свою песочницу. Там особо терять нечего.
Стартует все это практически моментально. У меня холодный старт на существующей песочнице (на hdd-хранилище) занял 627ms. Горячий старт туда же — 22ms. Так что я песочницами пользуюсь не только для сборки, но и для запуска всяких скачанных бинарников. А также для разграничения проектов. Менеджеры библиотек (которые для исходного кода, всякие mnv/npm/pip) обычно не умеют чистить кэш от того, что уже не нужно. В песочницах получается изолированная помойка, которую по завершению проекта можно просто убить со всем мусором. Ну и в качестве небольшого бонуса каждая песочница получает свою отдельную историю команд шелла, так что поиск в истории становится более релевантен.
BFE>Особенно если учесть, что следующая естественная команда, это sudo make install...
Не, это не естественная команда. Следующим идет естественный вопрос: а как я это все буду удалять после установки? У меня почти во всех случаях приложение в систему не нужно устанавливать. Я его запускаю в той же песочнице, в которой оно собрано. Есть исключение — драйвера для рулевого колеса (new-lg4ff). Они собираются в модули ядра. В нем я сам смотрел Makefile и даже пролистал код драйвера. Если же вдруг возникнет необходимость установить что-то в систему (а не в мою песочницу), тогда я все-таки осилю portage и напишу ebuild. Системный пакетный менеджер собирает в chroot. В том же chroot он выполняет install и уже потом переносит файлы в основную систему. Таким образом он прекрасно знает, что за файлы будут установлены (и потом должны быть удалены) и возникают ли конфликты с другими установленными пакетами.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Можно перечислить хотя бы первые три из "многочисленных" проблем, а также описать варианты случайного и намеренного "подсовывания" программы?
Ну вот скачал ты архив, распаковал, заходишь в каталог и пишешь `dir`, чтобы посмотреть список файлов. А там раз и `dir.exe` запускается из текущего каталога. Нежданчик. В винде может быть это не так выражено, там консоль такая убогая, что туда заходят только по большой нужде, а в юниксах консоль удобная и многие ей пользуются вместо файлового менеджера.
Здравствуйте, netch80, Вы писали:
N>Не вижу причины. Лежит себе исполняемый файл в каталоге. Запускать его пока никто не собирается. Но, может, каталог скопируют целиком в другое место, где уже будут запускать. Что не так и почему на сейчас не должно быть таких прав?
Потому, что это уязвимость, что очевидно. Нельзя давать архиватору самому выбирать фолдер, нельзя давать ему возможность создавать исполняемые файлы, нельзя давать права перезаписывать файлы и тд.
Вероятно, вы слишком долго сидите на линуксе, и не представляете, что именно на таких вещах можно сварганить чудовищное количество эксплойтов.
Сама идея архиватором распаковывать выполняемые файлы, скрипты итд, сильно порочная. Эдакий кастомный вариант инсталяции. На таких вот полу-инсталяторах в свое время жило не одно поколение троянов в Виндовс.
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, CreatorCray, Вы писали:
P>>>если вы запустите exe который попал в систему вне контроля инсталятора, операционка вам выдаёт варнинг. CC>>Да ну! CC>>И где такое чудо можно увидеть?
P>Давно уже в винде — запускаешь скачаный файл, винда кидает предупреждение. Подозреваю, ты это отключил.
Microsoft security в чистом виде: атрибутом помечен именно скачанный файл, а не, как было бы в нормальном варианте, атрибут (лучше как цифровая подпись) на проверенном и разрешённом файле. И, естественно, не все браузеры его ставят, этот атрибут. И не все скачанные файлы могут быть им помечены потому что идут не из Интернета.
Я могу только пособолезновать твоему уровню понимания секьюрити, раз такое советуешь
Здравствуйте, Shmj, Вы писали:
S>Зачем же? Лишняя сущность...
В Windows или Powershell?
Сделали это для безопасности.
По умолчанию ищет только в переменной окружения PATH.
Хочешь запустить именно из текущего каталога — добавляй префикс ./
Здравствуйте, Pauel, Вы писали:
P>·>Про который из них? Их как грязи, даже в винде. Так как операционка будет определять менеджер это или архиватор? Особенно с учётом того, что менеджер в своём составе может иметь тот же архиватор. P>Вы там из 90х пишете? P>В линуксе нет внятного апи инсталяции, пакетные менеджеры это лебедь рак да щука.
MSI??! Спасибо, не надо, сами такое кушайте.
P>Поскольку пакетный менеджер — часть операционки, он имеет права создавать выполняемые файлы.
Ты конкретно говори, с деталями. Как операционка определяет, что пакетный менеджер, а что не очень? Предлагаешь ещё один атрибут для файлов ввести или что?
P>Архиватор — юзерская программа, по дефолту таких прав не имеет, и апи иснталяции вызывать не сможет.
Юзерам иногда надо иметь возможность ставить свои проги, без прав админа.
P>>>И затыкали дыру именно по причине троянов, а не просто так, ради прикола P>·>Угу, ичхз от троянов это практически не спасает. Потому что — ну кто на эти варнинги смотрит?! P>Какие еще варнинги?
У себя спроси. Ты сам написал: "операционка вам выдаёт варнинг".
P>Вам показывается модальный бокс. Что бы запустить файл, нужно или отключить эту фичу, или обратить внимание, согласиться с последствиям и нажать Run anyway.
И именно это и будет написано в инструкции как установить софтинку с трояном. Это не средство безопасности. Это костыль чтобы можно было разводить идиотов, что наша операционка супербезопасная, у нас же есть варнинги! Это уже с ActiveX и прочими макросами проходили, а воз и ныне там.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sheridan, Вы писали:
BFE>>Серьёзно? В 21-ом веке SSH-only? Без SFTP? у нормальных людей? Не верю! BFE>>А раз есть SFTP, то (с помощью плагина) Total Commander будет работать без проблем. S>Ну-ну. Запусти в TC тот-же top, например.
Зачем? для этого есть убогий терминал.
S>ssh — базово и массово применяется для управления серверами.
А я разве спорю? Речь шла исключительно о файловых операциях.
S> Плагинами к TC пользуются только фанатики TC, да и то, как показывает практика, только первое время.
У кого нет TC, те всяким файлзиллами пользуются.
S> Потом сначала в putty перепозают
Зачем putty?
S>и следом в wsl2+windows terminal
Ой да ладно! ssh можно откуда угодно запустить.
Использовать в 21-ом веке терминал для файловых операций, это всё равно, что смотреть на графический экран через замочную скважину. Оно, конечно, можно, но страшно неэффективно не неудобно.
Здравствуйте, B0FEE664, Вы писали:
BFE>Использовать в 21-ом веке терминал для файловых операций, это всё равно, что смотреть на графический экран через замочную скважину. Оно, конечно, можно, но страшно неэффективно не неудобно.
Использовать в 21м веке чтото кроме выделенных сетевых хранилищ — дальше по тексту.
Здравствуйте, Shmj, Вы писали:
S>Зачем же? Лишняя сущность...
Если это правда, то это как в UNIX.
В UNIX так сделано неспроста: выбор программы, которая запустится в ответ на команду, не должен зависеть от текущей директории. Это и небезопасно (мало ли что в текущей директории валяется, это может быть содержимое архива, скачанного из недоверенного источника) и в целом, может приводить к сюрпризам, усложняющим жизнь.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, netch80, Вы писали:
N>>Многочисленными проблемами безопасности при случайном или намеренно подсунутом запуске одноимённой программы из текущего каталога.
Pzz>В начале 70-х, когда UNIX только изобрели (а я уверен, что это решение было принято уже тогда) на безопасность всем было, по большому счету, начхать. Думаю, ребят скорее заботила консистентность поведения системы. Ну действительно, не дело это, когда выбор запускаемой программы зависит от текущей директории.
А "в начале 70-х" как раз запуск из текущего каталога допускался.
Запрет пошёл, насколько помню, где-то при переходе к System III и ранним BSD.
Здравствуйте, netch80, Вы писали:
N>Многочисленными проблемами безопасности при случайном или намеренно подсунутом запуске одноимённой программы из текущего каталога.
Можно перечислить хотя бы первые три из "многочисленных" проблем, а также описать варианты случайного и намеренного "подсовывания" программы?
Здравствуйте, Pzz, Вы писали:
Pzz>В UNIX так сделано неспроста: выбор программы, которая запустится в ответ на команду, не должен зависеть от текущей директории. Это и небезопасно (мало ли что в текущей директории валяется, это может быть содержимое архива, скачанного из недоверенного источника)
В UNIX архивы, скачанные из недоверенных источников, не только автоматически получают право на выполнение, но и автоматически исполняются?
Здравствуйте, Pzz, Вы писали:
Pzz>tar распаковывает с теми правами, с которыми запаковано.
Если так, то это явная глупость.
Pzz>А что он должен делать?
Сбрасывать флаг E при распаковке, если явно не указано обратное (соответствующим ключом командной строки).
Pzz>И как сохранять точные копии набора файлов, если tar будет умничать?
К сохранению претензий нет — только к восстановлению (распаковке).
Здравствуйте, netch80, Вы писали:
N>Такое впечатление, что ты сейчас упорствуешь только ради того, чтобы не сдаваться, где это уже не имеет смысла.
Дык ничего нового
Спасибо за информацию, кстати, в том числе историческую. Невоинственным невеждам сплошная польза.
Можешь посоветовать что-то из литературы по линуксу в виде книги, где подобные темы освещаются? (совсем базовым уровнем типа 0644/0755 я владею, а вот что там с umask — уже нет. Понятное дело, почитаю ман, но хотелось бы чего-то системного). Недавно столкнулся по работе с несозданием кор-дампа процессом, у которого setcap netadmin выставлен. Нагуглил в итоге, но ощущение противное, когда не понимашь систему концептуально, а скакание по манам и гуглам не даёт полноты картины.
Здравствуйте, vsb, Вы писали:
vsb>Ну вот скачал ты архив, распаковал, заходишь в каталог и пишешь `dir`, чтобы посмотреть список файлов. А там раз и `dir.exe` запускается из текущего каталога.
Как раз с dir этот номер не пройдет. Dir — внутренняя команда. Вот с внешними да, может. Видимо, не напрасно во многих конторах, занимающихся администрированием, не разрешают использовать консольные команды. Разрешают делать все только через GUI.
Здравствуйте, netch80, Вы писали:
N>помни, что их три.
Так я помню.
N>Продолжаю недоумевать причинам такого утверждения. Это только из-за форсирования префикса `./`?
Из-за деклараций о том, что он снижает риски, на фоне того, что в других местах риски снижать никто не собирался и не собирается.
N>Тебе привели случай с разархивацией только как пример. Источников же исполняемого файла с совпадающим названием может быть сколько угодно, архиватором они не ограничиваются.
Так я в курсе. По-хорошему, все такие источники должны требовать явное, прозрачное указание на возможность наделения файла правом исполнения. Если, конечно, нас действительно интересует безопасность.
N>Насколько я помню, первые случаи были связаны как раз с ручной подкладкой юзерами троянов для человека-рута с названиями типа ls, du.
Вот тоже странно, почему такие уязвимости привели к введению обязательного "./", а не к устранению возможности для обычного юзера что-то подсунуть администратору.
N>Такое впечатление, что ты сейчас упорствуешь только ради того, чтобы не сдаваться, где это уже не имеет смысла.
Я всегда упорствовал и буду упорствовать в том, что безопасность должна быть комплексной, а не костыльной.
Здравствуйте, vsb, Вы писали:
vsb>Ну вот скачал ты архив, распаковал, заходишь в каталог и пишешь `dir`, чтобы посмотреть список файлов. А там раз и `dir.exe`
И сколько известно таких архивов за всю историю винды?
Здравствуйте, netch80, Вы писали: N>2. Нет, не лишняя. Доказано опытом Unix.
UNIX!
Дед, обнови уже свой дисковод! Юникс морально настолько устарел, что уже даже не смешно ссылаться "а вот у нас в юниксе!...".
Это протухшая куча ошибочных парадигм. "Всё есть файл, везде текст, текст передаётся по pipes" — вы серьёзно??
А система прав вообще не выдерживает никакой критики! Мир "один комп — сотня юзеров" давно уже поменялся на "один комп — один юзер — МНОГО ПРОГРАММ", соотв. система прав должна опираться не на то, что может запусать "единственный юзер единственного ПК", а "что может делать программа на данном ПК". Как в ведроиде: доступ к адресам, диску, USB и т.п. Была бы такая система в винде, мы бы сильно ущемили возможности вирусни.
Здравствуйте, Baiker, Вы писали:
B>Да и какой идиот в 21 веке набирает dir??? У меня вот Total Commander — я вижу, ЧТО у меня в архиве (и поверь, этот список получен не через dir ). В ЧЁМ ПРОБЛЕМА??
Батенька, Вы не поверите — у нормальных людей есть много серверов с доступом SSH-only (в том числе виндовые)
Здравствуйте, Baiker, Вы писали:
Pzz>>В UNIX так сделано неспроста: выбор программы, которая запустится в ответ на команду, не должен зависеть от текущей директории.
B>Сомнительный постулат, выковырянный из известной дырки.
Был бы ты с научными результатами Корнеева из НИИЧАВО — имел бы какое-то правило так грубить.
B>В том и прелесть "текущей директории", что она может "немного кастомайзить" поведение программ. Или сохранять работоспособность.
Это дело программ, использовать оттуда данные или нет. Есть те, что используют.
B>Пример: написали обработчик вывода ls. А потом какой-нть очередной стоеросовый "поттеринг" наулучшайзил её несовместимыми изменениями и вывод поломался. И что делать? Откатить ls назад нельзя — от неё ещё какая-нть хрень зависит! А потому мы поставляем с программой "правильный ls".
B>Это просто пример, не надо забрызгивать монитор, пытаясь объяснить, как это неправильно. В ИТ вообще много чего неправильного, но ради РАБОТЫ костыли приемлемы.
Здравствуйте, netch80, Вы писали:
N>Ну вот заметь в Unix (в лице Android поверх линуксового ядра) она есть, а в винде — нет (ты сам сказал, я не проверял). Так кто устарел-то и не выдерживает критики?
Хочу заметить, что Андроид — это не Unix, и даже не Linux, про который, кстати, некоторые говорят такое: "Linux is not Unix"
Здравствуйте, Mr.Delphist, Вы писали:
B>>Да и какой идиот в 21 веке набирает dir??? У меня вот Total Commander — я вижу, ЧТО у меня в архиве (и поверь, этот список получен не через dir ). В ЧЁМ ПРОБЛЕМА?? MD>Батенька, Вы не поверите — у нормальных людей есть много серверов с доступом SSH-only (в том числе виндовые)
Серьёзно? В 21-ом веке SSH-only? Без SFTP? у нормальных людей? Не верю!
А раз есть SFTP, то (с помощью плагина) Total Commander будет работать без проблем.
Здравствуйте, netch80, Вы писали:
N>При этом в половине случаев окажется, что GUI внутри себя зовёт консольную команду
Это настолько зашквар что наговнокодившего такое полагается гнать ссаными тряпками.
Здравствуйте, CreatorCray, Вы писали:
N>>При этом в половине случаев окажется, что GUI внутри себя зовёт консольную команду CC>Это настолько зашквар что наговнокодившего такое полагается гнать ссаными тряпками.
Капец ты наивный.
"Других людей у меня для вас нет" ([товарищ Коба]).
Ну и это в винде, может, зашквар с её проблемами что не-GUI прилада должна иметь консоль, от чего на экране регулярно вспыхивают полсекундные окна какого-нибудь powershell. В юниксах этого маразма нет.
Здравствуйте, Pauel, Вы писали:
N>>Не вижу причины. Лежит себе исполняемый файл в каталоге. Запускать его пока никто не собирается. Но, может, каталог скопируют целиком в другое место, где уже будут запускать. Что не так и почему на сейчас не должно быть таких прав?
P>Потому, что это уязвимость, что очевидно.
Нет, не очевидно.
P> Нельзя давать архиватору самому выбирать фолдер,
Он не выбирает.
P> нельзя давать ему возможность создавать исполняемые файлы,
Необоснованно.
P> нельзя давать права перезаписывать файлы
Регулируется. Но в общем случае проблемы нет уже тем, что нет мифического "самому выбирать фолдер".
P> и тд.
Что "и т.д."?
P>Вероятно, вы слишком долго сидите на линуксе, и не представляете, что именно на таких вещах можно сварганить чудовищное количество эксплойтов.
Рассказывайте. Что и как эксплойтится.
P>Сама идея архиватором распаковывать выполняемые файлы, скрипты итд, сильно порочная. Эдакий кастомный вариант инсталяции. На таких вот полу-инсталяторах в свое время жило не одно поколение троянов в Виндовс.
Подробности в студию. А там посмотрим, кто же был на самом деле виноват.
Здравствуйте, netch80, Вы писали:
N>Ну судя по тому как регулярно появляются окна всяких cmd и powershell на долю секунды (при установке/апгрейде чего-то — особенно, при старте системы), никто об этом не заботится.
Ну да, бывает, в инсталяторах. Особенно у программ перенесенных на винду с линукса. Не редкость когда для её установки, бывает даже не для работы, а для установки, требуется какой-нибудь перл, рhр питон, а для его установки какой-нибудь цигвин/мингв и все это при установке мусорит в консоль.
N>>Ну судя по тому как регулярно появляются окна всяких cmd и powershell на долю секунды (при установке/апгрейде чего-то — особенно, при старте системы), никто об этом не заботится. N>>А как именно сделать без них? CC>Пользоваться API а не скриптотой.
Могут быть ситуации, когда API отсутствует, либо нет binding`а для нужного языка.
Например для GDB штатный способ взаимодействия с фронтэндами это GDB’s Machine Interface, хотя библиотеки тоже есть (libgdb.a).
GDB/MI is a line based machine oriented text interface to GDB and is activated by specifying using the --interpreter command line option (see Mode Options).
It is specifically intended to support the development of systems which use the debugger as just one small component of a larger system.
Также для git я предпочту фронтэнды, которые запускают консольную версию git, чтобы было понятно, какие команды и параметры используются.
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, Conductor, Вы писали:
C>>1. А что, в винде если исполнимый файл в архив запаковать, то после распаковки он перестанет быть исполнимым? Нет.
P>Цитирую себя P>"Сама идея архиватором распаковывать выполняемые файлы, скрипты итд, сильно порочная. Эдакий кастомный вариант инсталяции. На таких вот полу-инсталяторах в свое время жило не одно поколение троянов в Виндовс."
И? Кто мешает всобачить зловреда в инсталлятор, который по сути и есть архив? Реальная защита что с архивом, что с инсталлятором одинаковая и она суть организационные меры: брать из надежных источников (критерии надёжности могут быть разными), проверять заявленную контрольную сумму, смотреть содержимое, если есть желание, то проверять аннтивирем, тестировать в песочнице и т.д. А ежели я архив распаковал или инсталлятор запустил, то значит принял решение, что это действие допустимо, и взял ответственность на себя. И я хочу видеть после распаковки то, что было упаковано.
Здравствуйте, CreatorCray, Вы писали:
P>>если вы запустите exe который попал в систему вне контроля инсталятора, операционка вам выдаёт варнинг. CC>Да ну! CC>И где такое чудо можно увидеть?
Давно уже в винде — запускаешь скачаный файл, винда кидает предупреждение. Подозреваю, ты это отключил.
Здравствуйте, B0FEE664, Вы писали:
BFE>Серьёзно? В 21-ом веке SSH-only? Без SFTP? у нормальных людей? Не верю! BFE>А раз есть SFTP, то (с помощью плагина) Total Commander будет работать без проблем.
Ну-ну. Запусти в TC тот-же top, например.
ssh — базово и массово применяется для управления серверами. Плагинами к TC пользуются только фанатики TC, да и то, как показывает практика, только первое время. Потом сначала в putty перепозают и следом в wsl2+windows terminal
Здравствуйте, B0FEE664, Вы писали:
BFE>Как вы, параноики, от этого защищаетесь?
Полно вариантов: fakeroot, mock, docker, отдельный пользователь, отдельная виртуалка.
BFE>Особенно если учесть, что следующая естественная команда, это sudo make install...
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Mr.Delphist, Вы писали:
BFE>Серьёзно? В 21-ом веке SSH-only? Без SFTP? у нормальных людей? Не верю!
BFE>А раз есть SFTP, то (с помощью плагина) Total Commander будет работать без проблем.
Вообще я фанат TC. Первые деньги, которые я отдал за лицуху был ТС, просто как дань уважения автору (всё остальное у меня было пиратское на тот момент). Первый софт, который я копирую на новую машину — это ТС.
И, конечно, у меня есть плагин для SFTP. И раньше я им активно пользовался.
Но конкретно сегодня большинство файловых операций со своими, лабовскими и клиентскими серверами я делаю через терминал.
Причины:
Я могу повторить копирование, которое я делал позавчера или неделю назад, за секунду. Ctrl-R + поиск среди команд scp при правильно настроенном шелле — это сильно быстрее, чем в TC перейти в нужный сервак и подпапку. Я уже не говорю о том, что на небыстрых соединениях просто получение списка файлов в UI — это тоже заметное время.
Я могу это легко автоматизировать. скопировать новый бинарь/бинари на несколько серваков в одну строчку. Скопировать только 5 самых свежих файлов и т.п.
Я могу использовать rsync.
На длинных операциях ТС может начать меня спрашивать, что делать с файлами, которые уже есть, а я отошёл/переключился на другой десктоп и т.п. И пока я не вернусь, операция будет ждать моего ответа. С scp/rsync я могу сразу сказать, какое поведения я хочу, и уйти пить кофе.
Кроме того, мне один фиг нужно настраиваить свой ~/.ssh под wsl, копировать туда ключи и прочее. Для ТС это отдельный этап настройки.
И не уверен, что TC сможет прорваться через jump host (не пробовал).
Наверняка есть ещё причины, но навскидку вот это всё — то, почему я пользуюсь терминалом.
И да, я чистый виндузятник, текущий проект linux-only и это первый такой проект в моей практике, так что подозревать меня к тяготению к линуксячничеству не стоит.
Здравствуйте, ·, Вы писали:
P>>·>Могу смело предположить, что линухов в мире больше, в каждой кофеварке. А если говорить о пользовательских устройствах и неквалифицированных пользователях, то маки тоже ужасно популярны. Однако трояны Win-only, даже часто под wine работать не хотят. P>>Трояны давно освоили андроид, айфон и макось. Вы продолжаете писать из 90х ·>Я WannaCry о твоих познаниях. ZeroAccess и т.п. это совсем не 90е. Вирусня в андроиде/етс существует на уровне легенд.
Трояны-вирусня в Android таки существует и достаточно много. Но она прорывается не через штатные механизмы безопасности, а как раз через разные лазейки, которые пристроены между ними специально для того, чтобы в этих условиях (по мнению их авторов) обеспечить комфортную работу. Их быстро затыкают, и вопрос найти такого поставщика, что делает обновления прошивок.
Или часть из них, как на моём старом Fly, проникает вообще через GSM-чип, который значительно сложнее лечить и обновлять.
Так что проблема есть, но это аргумент против выводов коллеги Pauel
·>Ну нету никакой группы администраторов в линухах, потому и спрашиваю что имеется в виду. А sudo без пароля вроде требует интерактива, поэтому неясно в чём проблема.
sudo без пароля как раз интерактива не требует, для того и придумано.
Но разумные люди настраивают его только на конкретные команды.
Здравствуйте, Shmj, Вы писали:
S>Зачем же? Лишняя сущность... Интересное дело. Поиск и в текущей директории и в PATH — эта фича тянется еще с ранних версий MS-DOS с восемдесят бородатого года.
Не прошло и полвека, как решили исправить.
Я может и прошло, если считать CP/M. Как там было с сабжем в CP/M не знаю, не копенгаген.
А вот интересно, если добавить текущий каталог в PATH, можно ли эмулировать старое поведение?..
PS. А официальное подтверждение со ссылками можно? Хочу понять с какой версии действует это изменение...
Расходимся, описанное поведение касается только PowerShell, ничего нового.
Здравствуйте, Shmj, Вы писали:
BSO>>PS. А официальное подтверждение со ссылками можно? Хочу понять с какой версии действует это изменение... S>Тут дело в том что по умолчанию как терминал теперь открывается PowerShell. И даже цвет убрали — ранее по умолчанию она была синей, а теперь черная. S>Ну и я не глянул, подумал что стандартная консоль, т.к. открылась по терминалу и черного цвета. А оно ПоверШелл.
PowerShell это одно, а cmd.exe — это другое , нельзя сравнивать.
В PowerShell описанное тобой поведение было изначально.
Я правильно понял, что поведение cmd.exe не изменилось, ты имел в виду только PowerShell???
Здравствуйте, netch80, Вы писали:
N>Многочисленными проблемами безопасности при случайном или намеренно подсунутом запуске одноимённой программы из текущего каталога.
В начале 70-х, когда UNIX только изобрели (а я уверен, что это решение было принято уже тогда) на безопасность всем было, по большому счету, начхать. Думаю, ребят скорее заботила консистентность поведения системы. Ну действительно, не дело это, когда выбор запускаемой программы зависит от текущей директории.
Здравствуйте, Pzz, Вы писали:
Pzz>Думаю, ребят скорее заботила консистентность поведения системы.
Вот разве что.
Pzz>действительно, не дело это, когда выбор запускаемой программы зависит от текущей директории.
Если все команды набираются вручную, и в каких-то каталогах лежат наборы тематических скриптов, то удобнее работать с ними из их собственного каталога, нежели прописывать в PATH или добавлять "./".
Здравствуйте, Pzz, Вы писали:
Pzz>Ну вот ты выкачиваешь foo.tar.gz. Распаковываешь. Заходишь внутрь. А там лежит файл с именем ls, правами 0755 и таким вот содержимым:
Pzz>
Pzz>#!/bin/sh
Pzz>rm -rf $HOME
Pzz>
Pzz>А ты, такой, говоришь ls стоя в этой внутренней директории, вынутой из архива. Ну, чтобы список файлов посмотреть.
Вы действительно полагаете, что именно подмена ls является наиболее существенным риском в этой схеме?
И что, tar по умолчанию распаковывает с правами выполнения? (я недостаточно близко знаком с унихами, не обращал на это внимания).
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И что, tar по умолчанию распаковывает с правами выполнения? (я недостаточно близко знаком с унихами, не обращал на это внимания).
tar распаковывает с теми правами, с которыми запаковано. А что он должен делать? И как сохранять точные копии набора файлов, если tar будет умничать?
UNIX-овский подход очень простой: файл делает исполняемым сочетание прав и положения в пути. Поэтому распаковать в просто какую-то временную директорию относительно безопасно (относительно — потому, что в имени файла может быть ESC-последовательность, которая "отразится" от терминала вредной командой — но это уже зловредство совершенно другого порядка)
Здравствуйте, Pzz, Вы писали:
Pzz>потому, что в имени файла может быть ESC-последовательность, которая "отразится" от терминала вредной командой — но это уже зловредство совершенно другого порядка)
ls по умолчанию такие символы экранирует.
$ touch `printf "\x1b[999m"`
$ ls
''$'\033''[999m'
$ ls -b
\033[999m
Здравствуйте, netch80, Вы писали:
N>А "в начале 70-х" как раз запуск из текущего каталога допускался. N>Запрет пошёл, насколько помню, где-то при переходе к System III и ранним BSD.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, netch80, Вы писали:
N>>ls по умолчанию такие символы экранирует.
Pzz>Ну он не всегда был таким умным...
По-моему, таки очень давно, только умолчательная экранировка была другая — например просто писался '?' на все непечатные (!isprint(c)) символы (во FreeBSD я очень долго помню такой режим).
Ну и разумеется это всё если опознано что на терминал. Иначе экранировка не включалась.
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>tar распаковывает с теми правами, с которыми запаковано.
ЕМ>Если так, то это явная глупость.
Pzz>>А что он должен делать?
ЕМ>Сбрасывать флаг E при распаковке, если явно не указано обратное (соответствующим ключом командной строки).
С чего бы это? Зачем было бы нужно такое умолчание?
Здравствуйте, Евгений Музыченко, Вы писали:
N>>С чего бы это? Зачем было бы нужно такое умолчание?
ЕМ>С того же и затем же, что по умолчанию файлы создаются без флага E, он всегда устанавливается явно.
Во-первых, что такое флаг E? Ты о какой ОС вообще говоришь? Если про Unix семейство (думаю, раз пошёл разговор в подветке), то там есть 3 флага: S_IXUSR,S_IXGRP, S_IXOTH (user, group, other соответственно). В стандартном выводе ls в формате вывода -rwxrwxrwx это все x соответственно.
Во-вторых, никакого такого умолчания нет, тебя обманули. На каждое создание файла 3-й аргумент open() и аналогичные аргументы всяких более современных openat() содержат полную маску, которая затем сбрасывается по текущей umask процесса (которая обычно, средствами init-процесса, установлена в 0o22, то есть S_IWGRP|S_IWOTH (заметь, это не флаги исполнения!) или почему-то в современных редхатоидах и дебианоидах в 002 (я исправляю у себя).
Ты можешь вызвать open(path, O_CREAT|..., S_IRUSR|S_IWUSR|S_IXUSR), например, и он будет исполняемым с ходу, но только для владельца. Часто такие маски пишут идиомами, и, например, 0644 — стандартные права для неисполняемого, 0755 — для исполняемого.
Так что пересмотри свои знания и не пори чушь.
(PS: На самом деле, в некоторых ситуациях, как минимум, не вредно создавать вначале файл с минимальными правами и только после заливки всего содержимого ставить полный комплект. Так вот — сюрприз — обычные tar типа GNU реализации именно так и делают! Так что и тут проблемы нет.)
Здравствуйте, netch80, Вы писали:
N>что такое флаг E?
"x". Я не юниксоид, мне простительно.
N>Ты о какой ОС вообще говоришь? Если про Unix семейство
Ага.
N>Во-вторых, никакого такого умолчания нет, тебя обманули. На каждое создание файла 3-й аргумент open() и аналогичные аргументы всяких более современных openat() содержат полную маску, которая затем сбрасывается по текущей umask процесса
Если в open() явно не указаны S_IXxxx, то у файла "они сами" собой (за счет попутной коррекции) не возникнут, а вот другие флаги — могут. Это и есть "умолчание".
N>Ты можешь вызвать open(path, O_CREAT|..., S_IRUSR|S_IWUSR|S_IXUSR), например, и он будет исполняемым с ходу
За это отвечает тот, кто такое использует.
Если действительно заботиться о безопасности, то нет никаких оснований позволять архиватору восстанавливать файлы с правами выполнения без явного на это указания. Ситуация, в которой никак не ограничивается создание исполняемых файлов "втихую", но при этом необходимость префикса "./" подается, как "мера безопасности", выглядит весьма уродливо.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>что такое флаг E? ЕМ>"x". Я не юниксоид, мне простительно.
Ладно. Но помни, что их три. (Пять, если считать с suid и sgid.)
N>>Во-вторых, никакого такого умолчания нет, тебя обманули. На каждое создание файла 3-й аргумент open() и аналогичные аргументы всяких более современных openat() содержат полную маску, которая затем сбрасывается по текущей umask процесса
ЕМ>Если в open() явно не указаны S_IXxxx, то у файла "они сами" собой (за счет попутной коррекции) не возникнут, а вот другие флаги — могут. Это и есть "умолчание".
Неправда. "Другие" не возникнут.
Если ты поставишь начальную маску прав 0, будет 0 (и записать в такой ничего не сможешь, но открыть сможешь).
Если ты не поставить флаги права записи, не будет права записи. Ядро не проявит никакой инициативы добавить другие флаги.
Так что нет тут никакого "умолчания" в ядре.
Есть только традиции открывать, да, по умолчанию с определёнными флагами, но это уже не уровень ядра.
N>>Ты можешь вызвать open(path, O_CREAT|..., S_IRUSR|S_IWUSR|S_IXUSR), например, и он будет исполняемым с ходу ЕМ>За это отвечает тот, кто такое использует.
Да.
ЕМ>Если действительно заботиться о безопасности, то нет никаких оснований позволять архиватору восстанавливать файлы с правами выполнения без явного на это указания.
Продолжаю недоумевать причинам такого утверждения. Это только из-за форсирования префикса `./`?
EM> Ситуация, в которой никак не ограничивается создание исполняемых файлов "втихую", но при этом необходимость префикса "./" подается, как "мера безопасности", выглядит весьма уродливо.
Тебе привели случай с разархивацией только как пример. Источников же исполняемого файла с совпадающим названием может быть сколько угодно, архиватором они не ограничиваются.
Насколько я помню, первые случаи были связаны как раз с ручной подкладкой юзерами троянов для человека-рута с названиями типа ls, du. Потом проблема была осознана и для административных скриптов.
Такое впечатление, что ты сейчас упорствуешь только ради того, чтобы не сдаваться, где это уже не имеет смысла.
Здравствуйте, Pzz, Вы писали:
Pzz> Ну действительно, не дело это, когда выбор запускаемой программы зависит от текущей директории.
честно, не понял формулировки
Чтобы выбор запускаемой программы не зависел от текущей директории, путь должен быть абсолютным, а не путём относительно текущей директории.
./my.exe — это же путь относительно текущей директории.
Здравствуйте, CRT, Вы писали:
Pzz>> Ну действительно, не дело это, когда выбор запускаемой программы зависит от текущей директории.
CRT>честно, не понял формулировки
Венда/DOS сначала ищут в текущей директории, а потом уже в пути...
Здравствуйте, Pzz, Вы писали:
Pzz>Венда/DOS сначала ищут в текущей директории,
я это знаю.
но когда ты в терминале пишешь ./my.exe , то что будет запущено, зависит таки от текущей директории, а ты говоришь "не дело это, когда выбор запускаемой программы зависит от текущей директории".
В одной директории один my.exe, в другой — другой. И в зависимости в какой ты директории стоишь, твоя команда ./my.exe запустит разные my.exe
Pzz>а потом уже в пути...
Здравствуйте, CRT, Вы писали:
CRT>но когда ты в терминале пишешь ./my.exe , то что будет запущено, зависит таки от текущей директории, а ты говоришь "не дело это, когда выбор запускаемой программы зависит от текущей директории".
А вот когда ты просто пишешь my.exe, то в венде выбор зависит, а в UNIX — нет.
Pzz>>а потом уже в пути...
CRT>не в пути, а в путях указанных в переменной PATH
Здравствуйте, serg_joker, Вы писали:
_>Спасибо за информацию, кстати, в том числе историческую. Невоинственным невеждам сплошная польза. _>Можешь посоветовать что-то из литературы по линуксу в виде книги, где подобные темы освещаются? (совсем базовым уровнем типа 0644/0755 я владею, а вот что там с umask — уже нет. Понятное дело, почитаю ман, но хотелось бы чего-то системного). Недавно столкнулся по работе с несозданием кор-дампа процессом, у которого setcap netadmin выставлен. Нагуглил в итоге, но ощущение противное, когда не понимашь систему концептуально, а скакание по манам и гуглам не даёт полноты картины.
Я считай после ~2000 именно на базовую литературу подобного рода не смотрел, только уже на сильно более специализированное. А из тех времён было несколько книг вполне симпатичных:
1. Робачевский "Операционная система Unix" — тут больше ориентация на программирование и базовое API, но очень системно.
2. "Секреты Unix" — несмотря на название это просто систематическое обширное введение как для пользователя. Там все эти особенности поданы уже с точки зрения что они значат и как используются — а это существенно.
3. Книги от Richard W. Stevens по общему ("Advanced programming in Unix environment") и сетевому программированию, были и в переводе.
4. Eric Raymond — "TAoUP" — это уже в основном не что вызывать а зачем его вызывать
В принципе этого хватало как для отличного старта. Эти три не учитывают множество новшеств типа контейнеров (разве что их предков типа chroot/jail), at-семейство функций, продвинутый AIO, очень мало про многонитевость. Но база есть и хорошо рассмотрена.
Про встроенную документацию: "маны" это уже справочник, их читать можно только уже зная, куда идти. Дальше нужно делать, например, как всегда у Microsoft — на любую подсистему три секции: обзор, howto для типичных случаев, и справочник (аналогичный манам). Для обзора годятся, например, Developers Handbook, но это для FreeBSD, многое для Linux уже совсем другое. С ходу аналогичных примеров для Linux не нашёл — хм, их сейчас нет или просто не вспомнилось? Можно, конечно, начать с info libc, там тоже иерархический метод, но там не будет множества тонкостей.
Сейчас перечитал это — хм, выглядит странным, что нет какого-то ни онлайн ни бумажного новшества — или давно не обновлялись, или я просто не замечаю. Кто бы прокомментировал.
Здравствуйте, vsb, Вы писали:
vsb>Ну вот скачал ты архив, распаковал, заходишь в каталог и пишешь `dir`, чтобы посмотреть список файлов. А там раз и `dir.exe` запускается из текущего каталога. Нежданчик. В винде может быть это не так выражено, там консоль такая убогая, что туда заходят только по большой нужде, а в юниксах консоль удобная и многие ей пользуются вместо файлового менеджера.
Файловый менеджер обычно использует тот же PATH, если команда набирается явно, а не в варианте ткнуть Enter на исполняемом файле.
vsb>Ну а если хочется — добавить `.` в PATH недолго.
Здравствуйте, Privalov, Вы писали:
vsb>>Ну вот скачал ты архив, распаковал, заходишь в каталог и пишешь `dir`, чтобы посмотреть список файлов. А там раз и `dir.exe` запускается из текущего каталога.
P>Как раз с dir этот номер не пройдет. Dir — внутренняя команда. Вот с внешними да, может. Видимо, не напрасно во многих конторах, занимающихся администрированием, не разрешают использовать консольные команды. Разрешают делать все только через GUI.
При этом в половине случаев окажется, что GUI внутри себя зовёт консольную команду (для юникса — через любой шелл, для винды — через PowerShell или аналог).
Не знаю, что это за "многие конторы", но если обоснование такого запрета именно такое, то это совершенно клиническая глупость.
Больше похоже, что там рулят древние мудаки, для которых даже cmd.exe это новомод.
Здравствуйте, Pzz, Вы писали:
Pzz>В UNIX так сделано неспроста: выбор программы, которая запустится в ответ на команду, не должен зависеть от текущей директории.
Сомнительный постулат, выковырянный из известной дырки.
В том и прелесть "текущей директории", что она может "немного кастомайзить" поведение программ. Или сохранять работоспособность.
Пример: написали обработчик вывода ls. А потом какой-нть очередной стоеросовый "поттеринг" наулучшайзил её несовместимыми изменениями и вывод поломался. И что делать? Откатить ls назад нельзя — от неё ещё какая-нть хрень зависит! А потому мы поставляем с программой "правильный ls".
Это просто пример, не надо забрызгивать монитор, пытаясь объяснить, как это неправильно. В ИТ вообще много чего неправильного, но ради РАБОТЫ костыли приемлемы.
Здравствуйте, netch80, Вы писали:
N>1. Робачевский "Операционная система Unix" — тут больше ориентация на программирование и базовое API, но очень системно.
Никчемная книжка
N>3. Книги от Richard W. Stevens по общему ("Advanced programming in Unix environment") и сетевому программированию, были и в переводе.
Здравствуйте, vsb, Вы писали:
vsb>Ну вот скачал ты архив, распаковал, заходишь в каталог и пишешь `dir`, чтобы посмотреть список файлов. А там раз и `dir.exe` запускается из текущего каталога. Нежданчик.
Если с программой поставляется dir, то на это есть веские причины. Заменять вендовый dir (в смысле перезаписывать своим) — ВОТ ЭТО проблема! А запускать "свой вариант" dir — это нормально. Да и какой идиот в 21 веке набирает dir??? У меня вот Total Commander — я вижу, ЧТО у меня в архиве (и поверь, этот список получен не через dir ). В ЧЁМ ПРОБЛЕМА??
А если уж так ссышь запускать чужие кряки, на это есть Sandboxie.
Безопасность не повысить идиотскими ограничениями "не запускать что-то локальное". Это из серии горе-админов, которые запрещают USB-порты Безопасность должна КОНЦЕПТУАЛЬНО быть правильной, а лататели старого одеяла никогда не сделают его новым.
Здравствуйте, Baiker, Вы писали:
B>Здравствуйте, netch80, Вы писали: N>>2. Нет, не лишняя. Доказано опытом Unix.
B>UNIX! B>Дед, обнови уже свой дисковод!
От деда слышу. Причём неуместно агрессивного.
B> Юникс морально настолько устарел, что уже даже не смешно ссылаться "а вот у нас в юниксе!...". B>Это протухшая куча ошибочных парадигм. "Всё есть файл, везде текст, текст передаётся по pipes" — вы серьёзно??
То, что мы обсуждаем, не имеет отношения к данным "парадигмам" — которые не абсолютны, но всё равно доказали свою жизнестойкость.
B>А система прав вообще не выдерживает никакой критики! Мир "один комп — сотня юзеров" давно уже поменялся на "один комп — один юзер — МНОГО ПРОГРАММ",
Нет, это упрощение. Но ладно, рассмотрим в пределах такого упрощения.
B> соотв. система прав должна опираться не на то, что может запусать "единственный юзер единственного ПК", а "что может делать программа на данном ПК". Как в ведроиде: доступ к адресам, диску, USB и т.п. Была бы такая система в винде, мы бы сильно ущемили возможности вирусни.
Ну вот заметь в Unix (в лице Android поверх линуксового ядра) она есть, а в винде — нет (ты сам сказал, я не проверял). Так кто устарел-то и не выдерживает критики?
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, netch80, Вы писали:
N>>1. Робачевский "Операционная система Unix" — тут больше ориентация на программирование и базовое API, но очень системно.
M>Никчемная книжка
А мне очень помогла. Я не знаю, что ты там не посмотрел.
N>>3. Книги от Richard W. Stevens по общему ("Advanced programming in Unix environment") и сетевому программированию, были и в переводе.
M>Стивенс — голова
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Продолжаю недоумевать причинам такого утверждения. Это только из-за форсирования префикса `./`? ЕМ>Из-за деклараций о том, что он снижает риски, на фоне того, что в других местах риски снижать никто не собирался и не собирается.
В каких "других местах"? Это универсальный риск и он как раз и лечится.
N>>Тебе привели случай с разархивацией только как пример. Источников же исполняемого файла с совпадающим названием может быть сколько угодно, архиватором они не ограничиваются.
ЕМ>Так я в курсе. По-хорошему, все такие источники должны требовать явное, прозрачное указание на возможность наделения файла правом исполнения. Если, конечно, нас действительно интересует безопасность.
Не вижу причины. Лежит себе исполняемый файл в каталоге. Запускать его пока никто не собирается. Но, может, каталог скопируют целиком в другое место, где уже будут запускать. Что не так и почему на сейчас не должно быть таких прав?
N>>Насколько я помню, первые случаи были связаны как раз с ручной подкладкой юзерами троянов для человека-рута с названиями типа ls, du. ЕМ>Вот тоже странно, почему такие уязвимости привели к введению обязательного "./", а не к устранению возможности для обычного юзера что-то подсунуть администратору.
Так эта возможность и была устранена.
N>>Такое впечатление, что ты сейчас упорствуешь только ради того, чтобы не сдаваться, где это уже не имеет смысла. ЕМ>Я всегда упорствовал и буду упорствовать в том, что безопасность должна быть комплексной, а не костыльной.
Она и есть комплексная. А что костыльного в этом решении, ты никак не можешь объяснить. Зато зачем-то требуешь не ставить исполняемость без каких-то особых прав.
Здравствуйте, netch80, Вы писали:
N>>>3. Книги от Richard W. Stevens по общему ("Advanced programming in Unix environment") и сетевому программированию, были и в переводе.
M>>Стивенс — голова
N>Да, но тоже обновления давно нет.
Он как бы давно уже RIP, так что обновления можно не дождаться
Здравствуйте, Marty, Вы писали:
N>>>>3. Книги от Richard W. Stevens по общему ("Advanced programming in Unix environment") и сетевому программированию, были и в переводе.
M>>>Стивенс — голова
N>>Да, но тоже обновления давно нет.
M>Он как бы давно уже RIP,
Да, я в курсе.
M> так что обновления можно не дождаться
Там по слухам собирался коллектив обновить.
Но проблема в том, что обновление нужно радикальное.
F>Если пользоваться только одним томом (с, а остальные диски мапить как подкаталоги, то букву можно вообще не писать. И будет, как в линуксе или макоси.
Если бы! Слеши в обратную сторону. Поскольку я сейчас пишу мультиплатформу. Но вообще кто бы мне сказал лет 20 назад, что я буду писать на C#, на МакБуке, чтобы потом запускать написанное в Docker'е на Ubuntu...
Здравствуйте, Marty, Вы писали:
N>>Ну вот заметь в Unix (в лице Android поверх линуксового ядра) она есть, а в винде — нет (ты сам сказал, я не проверял). Так кто устарел-то и не выдерживает критики?
M>Хочу заметить, что Андроид — это не Unix, и даже не Linux, про который, кстати, некоторые говорят такое: "Linux is not Unix"
Для обсуждаемого вопроса он и Linux, и Unix (в широком смысле).
Его специфика начинается выше — специфические API, принципы администрирования, интерфейс пользователя.
Здравствуйте, CreatorCray, Вы писали:
SD>>Если бы! Слеши в обратную сторону. CC>Винда ж понимает слеши в путях в любую сторону.
Нет. Точнее, не тогда, когда это более нужно.
В том режиме, в котором она это понимает, включается легаси-разборщик пути, у которого длина ограничена, а всякие CON и AUX независимо от каталога и расширения это устройства — то есть этот режим вообще опасно звать.
А если потребовать UNC, понимание '/' как-то резко заканчивается.
По крайней мере на 10ке прошлого года было именно так.
Здравствуйте, netch80, Вы писали:
N>Ну и это в винде, может, зашквар с её проблемами что не-GUI прилада должна иметь консоль,...
Не должна конечно. Но если написана так, что имеет, то имеет.
Здравствуйте, pagid_, Вы писали:
_>Здравствуйте, netch80, Вы писали:
N>>Ну и это в винде, может, зашквар с её проблемами что не-GUI прилада должна иметь консоль,... _>Не должна конечно. Но если написана так, что имеет, то имеет.
Ну судя по тому как регулярно появляются окна всяких cmd и powershell на долю секунды (при установке/апгрейде чего-то — особенно, при старте системы), никто об этом не заботится.
А как именно сделать без них?
Здравствуйте, netch80, Вы писали:
N>>>Ну вот заметь в Unix (в лице Android поверх линуксового ядра) она есть, а в винде — нет (ты сам сказал, я не проверял). Так кто устарел-то и не выдерживает критики?
M>>Хочу заметить, что Андроид — это не Unix, и даже не Linux, про который, кстати, некоторые говорят такое: "Linux is not Unix"
N>Для обсуждаемого вопроса он и Linux, и Unix (в широком смысле). N>Его специфика начинается выше — специфические API, принципы администрирования, интерфейс пользователя.
Операционная система — это не только ядро, но и всё остальное. И вот всё остальное у Андроида — не линуксовое.
Здравствуйте, Marty, Вы писали:
N>>Для обсуждаемого вопроса он и Linux, и Unix (в широком смысле). N>>Его специфика начинается выше — специфические API, принципы администрирования, интерфейс пользователя.
M>Операционная система — это не только ядро, но и всё остальное. И вот всё остальное у Андроида — не линуксовое.
Вот потому Столлман настаивал на названии "GNU/Linux" ещё когда кроме GNU юзерленда ничего не было. Напророчил, так сказать.
Кстати, "не линуксовое" (в широком смысле) не "всё" у Android. Native слой имеет дофига общего.
Здравствуйте, Shmj, Вы писали:
S>Зачем же? Лишняя сущность...
Это нужно было делать с самого начала.
Лишняя или нет — это вопрос подхода. Мне лично больше нравится, когда пусть немного избыточно, но зато более однозначно и меньше подразумевается, меньше негласных правил нужно запоминать в таких противоречивых случаях как порядок поиска исполняемого файла, который для разных ОС вообще может отличаться, и что прикажешь — помнить все эти особенности?
Здравствуйте, Pauel, Вы писали:
N>>Не вижу причины. Лежит себе исполняемый файл в каталоге. Запускать его пока никто не собирается. Но, может, каталог скопируют целиком в другое место, где уже будут запускать. Что не так и почему на сейчас не должно быть таких прав?
P>Потому, что это уязвимость, что очевидно. Нельзя давать архиватору самому выбирать фолдер, нельзя давать ему возможность создавать исполняемые файлы, нельзя давать права перезаписывать файлы и тд.
P>Сама идея архиватором распаковывать выполняемые файлы, скрипты итд, сильно порочная. Эдакий кастомный вариант инсталяции. На таких вот полу-инсталяторах в свое время жило не одно поколение троянов в Виндовс.
1. А что, в винде если исполнимый файл в архив запаковать, то после распаковки он перестанет быть исполнимым? Нет.
2. Непосредственно по стартовой теме — логика понятная: защита от запуска не того, что предполагает запускающий. А снятие бита после распаковки ничего не меняет: он именно этот файл сознательно хочет запустить, а если хочет, то руками выставит бит и запустит, снимай — не снимай при распаковке.
Здравствуйте, netch80, Вы писали:
N>Капец ты наивный.
Даже в стартапе где надо было всё быстро-быстро и вообще вчера всё делалось через API а не через перевызовы сторонних бинарей.
N>"Других людей у меня для вас нет" ([товарищ Коба]).
Таких людей у нас есть.
Здравствуйте, netch80, Вы писали:
N>Ну судя по тому как регулярно появляются окна всяких cmd и powershell на долю секунды (при установке/апгрейде чего-то — особенно, при старте системы), никто об этом не заботится. N>А как именно сделать без них?
Пользоваться API а не скриптотой.
Здравствуйте, netch80, Вы писали:
N>Нет. Точнее, не тогда, когда это более нужно.
Это нужно только когда пути вводятся юзером ручками для передачи во всякие шеллы.
Во всех остальных случаях пути крайне просто привести к нормальному виду.
Проблема в целом не стОит выеденого яйца Пушкина (С).
Здравствуйте, CreatorCray, Вы писали:
N>>Капец ты наивный. CC>Даже в стартапе где надо было всё быстро-быстро и вообще вчера всё делалось через API а не через перевызовы сторонних бинарей.
Повезло со стартапом.
Меня вот работа на крупных проектах привела к осознанию, _насколько_ сейчас жесточайший кадровый дефицит именно в образованных культурных сотрудниках, которые хотя бы стараются выверять свои решения по нескольким основным критериям качества кода.
На одного такого не менее десяти тех, кому всё пофиг, пока тесты сданы.
Именно против таких вводятся статические анализаторы, автоформаттеры и прочие недо-ИИ.
N>>"Других людей у меня для вас нет" ([товарищ Коба]). CC>Таких людей у нас есть.
Не смеши мои тапочки, их уже взяли джунами на проект.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, netch80, Вы писали:
N>>Ну судя по тому как регулярно появляются окна всяких cmd и powershell на долю секунды (при установке/апгрейде чего-то — особенно, при старте системы), никто об этом не заботится. N>>А как именно сделать без них? CC>Пользоваться API а не скриптотой.
Здравствуйте, CreatorCray, Вы писали:
N>>Нет. Точнее, не тогда, когда это более нужно. CC>Это нужно только когда пути вводятся юзером ручками для передачи во всякие шеллы.
Что именно нужно и в каком виде?
CC>Во всех остальных случаях пути крайне просто привести к нормальному виду.
Есть для этого функция WinAPI? Если нет, то не считается.
CC>Проблема в целом не стОит выеденого яйца Пушкина (С).
Здравствуйте, netch80, Вы писали:
N>Что именно нужно и в каком виде?
Понимать если налепили слешей в неправильную сторону
N>Есть для этого функция WinAPI? Если нет, то не считается.
Может и есть, у меня давно свой FW для всего этого.
N>Если бы не стоила, не было бы двух вариантов API.
Два варианта API появились совершенно не поэтому.
Здравствуйте, Conductor, Вы писали:
C>1. А что, в винде если исполнимый файл в архив запаковать, то после распаковки он перестанет быть исполнимым? Нет.
Цитирую себя
"Сама идея архиватором распаковывать выполняемые файлы, скрипты итд, сильно порочная. Эдакий кастомный вариант инсталяции. На таких вот полу-инсталяторах в свое время жило не одно поколение троянов в Виндовс."
Здравствуйте, netch80, Вы писали:
P>>Сама идея архиватором распаковывать выполняемые файлы, скрипты итд, сильно порочная. Эдакий кастомный вариант инсталяции. На таких вот полу-инсталяторах в свое время жило не одно поколение троянов в Виндовс.
N>Подробности в студию. А там посмотрим, кто же был на самом деле виноват.
Вот смотрите, есть фолдер ~/.local/bin который в path. Некоторые софтины гадят прямо в ~/
Если распаковать архив прямо в этом фолдере, то может оказаться так, что в ~/.local/bin окажется выполняемый скрипт ls. Гы-гы.
У меня, например, в path еще три фолдера из ~/, в которые можно сунуть скриптец.
Факт в том, что пользователи регулярно совершают неосторожные, необдуманные действия. Даже больше — все пользователи совершают такое, разница только в частоте инцидентов и степени последствий.
Здравствуйте, Pauel, Вы писали:
P>Вот смотрите, есть фолдер ~/.local/bin который в path. Некоторые софтины гадят прямо в ~/
Это что такое за софтины и откуда они взялись?
Если допустить гадить в корень, то исполняемые файлы в ~/.local/bin это минимальная проблема. Там есть ~/.profile (.bash_profile), .bashrc и ещё много чего.
Причём в них как раз записать проще — там даже путь не нужен.
P>Если распаковать архив прямо в этом фолдере, то может оказаться так, что в ~/.local/bin окажется выполняемый скрипт ls. Гы-гы.
Какой-то совершенно мифический случай, для которого должны сойтись несколько дырок и при котором, повторюсь, исполняемые файлы это минимальная проблема.
P>У меня, например, в path еще три фолдера из ~/, в которые можно сунуть скриптец. P>Факт в том, что пользователи регулярно совершают неосторожные, необдуманные действия. Даже больше — все пользователи совершают такое, разница только в частоте инцидентов и степени последствий.
И они точно так же неосторожными действиями затрут важные файлы, от чего последствий будет больше.
Здравствуйте, pagid_, Вы писали:
_>Здравствуйте, netch80, Вы писали:
N>>Ну судя по тому как регулярно появляются окна всяких cmd и powershell на долю секунды (при установке/апгрейде чего-то — особенно, при старте системы), никто об этом не заботится. _>Ну да, бывает, в инсталяторах. Особенно у программ перенесенных на винду с линукса. Не редкость когда для её установки, бывает даже не для работы, а для установки, требуется какой-нибудь перл, рhр питон, а для его установки какой-нибудь цигвин/мингв и все это при установке мусорит в консоль.
Значит, "с линукса" перенесены инсталляторы самой винды, Visual Studio... я у них такое видел больше, чем у остальных.
Коллега, вы рассказываете интересные вещи о процессах разработки в Microsoft...
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, netch80, Вы писали:
N>>Что именно нужно и в каком виде? CC>Понимать если налепили слешей в неправильную сторону
Отлично. То есть с пользовательского ввода надо одновременно и воспринимать "неправильные" слэши и в то же время не допускать всяких CON и AUX.
В рамках предоставленного API эти требования взаимно противоречивы.
N>>Есть для этого функция WinAPI? Если нет, то не считается. CC>Может и есть, у меня давно свой FW для всего этого.
Значит, нет и не считается.
N>>Если бы не стоила, не было бы двух вариантов API. CC>Два варианта API появились совершенно не поэтому.
Здравствуйте, Pauel, Вы писали:
C>>1. А что, в винде если исполнимый файл в архив запаковать, то после распаковки он перестанет быть исполнимым? Нет. P>Цитирую себя P>"Сама идея архиватором распаковывать выполняемые файлы, скрипты итд, сильно порочная. Эдакий кастомный вариант инсталяции.
Бред. А как ещё создавать выполняемые файлы на целевой системе? Собирать компилятором из исходников? И чем архиватор отличается от любой другой программы? Как операционка должна решать кому можно расставлять x-атрибуты, а кому нельзя?
P>На таких вот полу-инсталяторах в свое время жило не одно поколение троянов в Виндовс."
Так ведь это проблема в Виндовз. Причём тут линухи?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
P>>Цитирую себя P>>"Сама идея архиватором распаковывать выполняемые файлы, скрипты итд, сильно порочная. Эдакий кастомный вариант инсталяции. ·>Бред. А как ещё создавать выполняемые файлы на целевой системе? Собирать компилятором из исходников? И чем архиватор отличается от любой другой программы? Как операционка должна решать кому можно расставлять x-атрибуты, а кому нельзя?
Про пакетный менеджер или инсталятор вы ничего не слышали, правильно понимаю?
P>>На таких вот полу-инсталяторах в свое время жило не одно поколение троянов в Виндовс." ·>Так ведь это проблема в Виндовз. Причём тут линухи?
В виндовс была ровно та же дыра, только больше — там пермишнов не нужно, достаточно расширения .exe. Была — потому, что пришлось кое как залатать.
Дыру пришлось заткнуть — если вы запустите exe который попал в систему вне контроля инсталятора, операционка вам выдаёт варнинг.
И затыкали дыру именно по причине троянов, а не просто так, ради прикола
Здравствуйте, netch80, Вы писали:
N>Это что такое за софтины и откуда они взялись?
Юзер сам поставил, разумеется. Вот скажем некоторые софтины используют zip в качестве проектного файла. Киданул в ~/ , распаковал, работаешь. А если подложить тот самый скриптец, то появятся весьма интересные последствия.
N>Если допустить гадить в корень, то исполняемые файлы в ~/.local/bin это минимальная проблема. Там есть ~/.profile (.bash_profile), .bashrc и ещё много чего. N>Причём в них как раз записать проще — там даже путь не нужен.
Именно — такие файлы архиватору тоже нельзя давать менять.
Более того, само наличие таких файлов в линукс говорит о том, что это каменный век. Были такие вирусы в начале времен MSDOS, которые модифицировали autoexec.bat и config.sys. Тогда это было смешно, т.к. всё было на виду, а вирусы коммерческой пользы не преследовали.
P>>Если распаковать архив прямо в этом фолдере, то может оказаться так, что в ~/.local/bin окажется выполняемый скрипт ls. Гы-гы.
N>Какой-то совершенно мифический случай, для которого должны сойтись несколько дырок и при котором, повторюсь, исполняемые файлы это минимальная проблема.
В свое время на винде ровно так же и рассуждали. А потом пришлось затыкать именно эти дыры. Сейчас трояны это денежный бизнес. Пользователей Линукс защищает исключительно хилая популярность системы, а не мифические свойства.
P>>Факт в том, что пользователи регулярно совершают неосторожные, необдуманные действия. Даже больше — все пользователи совершают такое, разница только в частоте инцидентов и степени последствий.
N>И они точно так же неосторожными действиями затрут важные файлы, от чего последствий будет больше.
История вирусни в msdos и вындоусе, похоже, для вас пустой звук.
Здравствуйте, Pauel, Вы писали:
N>>Это что такое за софтины и откуда они взялись? P>Юзер сам поставил, разумеется. Вот скажем некоторые софтины используют zip в качестве проектного файла. Киданул в ~/ , распаковал, работаешь. А если подложить тот самый скриптец, то появятся весьма интересные последствия.
"Киданул в хомяк" это пять. Косяков.
N>>Если допустить гадить в корень, то исполняемые файлы в ~/.local/bin это минимальная проблема. Там есть ~/.profile (.bash_profile), .bashrc и ещё много чего. N>>Причём в них как раз записать проще — там даже путь не нужен.
P>Именно — такие файлы архиватору тоже нельзя давать менять.
Осталось найти умный ИИ, который отделит архиватор от прочих приложений.
P>Более того, само наличие таких файлов в линукс говорит о том, что это каменный век.
Ага, любая кастомизация тогда это каменный век.
P>В свое время на винде ровно так же и рассуждали. А потом пришлось затыкать именно эти дыры. Сейчас трояны это денежный бизнес.
Только почему-то эти дырозащиты в принципе не работают в той схеме, как они задуманы, а трояны спокойно себе гуляют вдоль и поперёк.
Лечением реально оказались два подхода — тотальная подпись (работает, как любое огораживание через двуединую сущность опорного характера, только для особо терпеливых) и подход стиля Android, где приложения в своих клеточках (и то — очень долго залечивали проломы).
P> Пользователей Линукс защищает исключительно хилая популярность системы, а не мифические свойства.
Вы сделали 6 ошибок в слове "NetBSD".
P>>>Факт в том, что пользователи регулярно совершают неосторожные, необдуманные действия. Даже больше — все пользователи совершают такое, разница только в частоте инцидентов и степени последствий. N>>И они точно так же неосторожными действиями затрут важные файлы, от чего последствий будет больше. P>История вирусни в msdos и вындоусе, похоже, для вас пустой звук.
У меня есть сильное подозрение, что я эту историю застал плотнее вас.
Но я из этого не делаю выводы космического масштаба (продолжение фразы съела цензура).
Здравствуйте, m2user, Вы писали:
M>Могут быть ситуации, когда API отсутствует, либо нет binding`а для нужного языка.
Это к вопросу качества софта у красноглазиков.
M>Например для GDB штатный способ взаимодействия с фронтэндами это GDB’s Machine Interface, хотя библиотеки тоже есть (libgdb.a).
Надо отметить что GDB таки ужасен.
M>Также для git я предпочту фронтэнды, которые запускают консольную версию git, чтобы было понятно, какие команды и параметры используются.
Сам git это говно скриптота с кусочками фруктов.
Здравствуйте, netch80, Вы писали:
N>Значит, "с линукса" перенесены инсталляторы самой винды, Visual Studio...
Сколько вижуалок я уже ставил за декады — чот не припомню там моргающих окошек.
Или ты про высер под названием VS Code?
Здравствуйте, netch80, Вы писали:
N>Как говорят в некоторых структурах, "в любом расследовании главное — не выйти на себя самого".
Дети — цветы жизци...
N>Так что ты там поосторожнее.
Личным опытом делишься?
Здравствуйте, Pauel, Вы писали:
P>если вы запустите exe который попал в систему вне контроля инсталятора, операционка вам выдаёт варнинг.
Да ну!
И где такое чудо можно увидеть?
Здравствуйте, netch80, Вы писали:
N>А "в начале 70-х" как раз запуск из текущего каталога допускался. N>Запрет пошёл, насколько помню, где-то при переходе к System III и ранним BSD.
А потом, в 80-х, текущая директория (.) снова вернулась в $path в Plan 9.
Здравствуйте, korvin_, Вы писали:
_>Здравствуйте, netch80, Вы писали:
N>>А "в начале 70-х" как раз запуск из текущего каталога допускался. N>>Запрет пошёл, насколько помню, где-то при переходе к System III и ранним BSD.
_>А потом, в 80-х, текущая директория (.) снова вернулась в $path в Plan 9.
Так вручную можно добавить в любом юниксе, но умолчания такого нет и не советуют.
А в Plan 9, что, умолчание?
Здравствуйте, Pzz, Вы писали:
Pzz>в имени файла может быть ESC-последовательность, которая "отразится" от терминала вредной командой — но это уже зловредство совершенно другого порядка)
Здравствуйте, CreatorCray, Вы писали:
N>>Как говорят в некоторых структурах, "в любом расследовании главное — не выйти на себя самого". CC>Дети — цветы жизци...
Велик могучим русский языка.
N>>Так что ты там поосторожнее. CC>Личным опытом делишься?
Здравствуйте, Pauel, Вы писали:
P>>>"Сама идея архиватором распаковывать выполняемые файлы, скрипты итд, сильно порочная. Эдакий кастомный вариант инсталяции. P>·>Бред. А как ещё создавать выполняемые файлы на целевой системе? Собирать компилятором из исходников? И чем архиватор отличается от любой другой программы? Как операционка должна решать кому можно расставлять x-атрибуты, а кому нельзя? P>Про пакетный менеджер или инсталятор вы ничего не слышали, правильно понимаю?
Про который из них? Их как грязи, даже в винде. Так как операционка будет определять менеджер это или архиватор? Особенно с учётом того, что менеджер в своём составе может иметь тот же архиватор.
P>>>На таких вот полу-инсталяторах в свое время жило не одно поколение троянов в Виндовс." P>·>Так ведь это проблема в Виндовз. Причём тут линухи? P> В виндовс была ровно та же дыра, только больше — там пермишнов не нужно, достаточно расширения .exe. Была — потому, что пришлось кое как залатать.
Я точно историю не знаю, но по ощущениям в линухах эту дыру залатали ещё когда винды в планах даже не было.
P>Дыру пришлось заткнуть — если вы запустите exe который попал в систему вне контроля инсталятора, операционка вам выдаёт варнинг.
Это не залатали, это костыль присобачили.
P>И затыкали дыру именно по причине троянов, а не просто так, ради прикола
Угу, ичхз от троянов это практически не спасает. Потому что — ну кто на эти варнинги смотрит?!
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, serjjj, Вы писали:
Pzz>>в имени файла может быть ESC-последовательность, которая "отразится" от терминала вредной командой — но это уже зловредство совершенно другого порядка)
S>А можно с этого места поподробнее?
Здравствуйте, Pauel, Вы писали:
P>У меня, например, в path еще три фолдера из ~/, в которые можно сунуть скриптец.
Потому что ты разраб и себе в ногу стрельнул кривым софтом. Вот у меня загалило path только поделие микрософта (ну не могут они в безопасность):
Здравствуйте, ·, Вы писали:
P>>У меня, например, в path еще три фолдера из ~/, в которые можно сунуть скриптец. ·>Потому что ты разраб и себе в ногу стрельнул кривым софтом.
Телепатия вас подводит, как и всегда. ~/.local/bin — к этому фолдеру я не имею никакого отношения.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, serjjj, Вы писали:
Pzz>>>в имени файла может быть ESC-последовательность, которая "отразится" от терминала вредной командой — но это уже зловредство совершенно другого порядка)
S>>А можно с этого места поподробнее?
Pzz>Что именно непонятно?
Про ESC-последовательности я знаю, но чтобы выполнить любую произвольную команду (например, rm -rf $HOME)... Нужен пример.
Здравствуйте, Pauel, Вы писали:
P>>>У меня, например, в path еще три фолдера из ~/, в которые можно сунуть скриптец. P>·>Потому что ты разраб и себе в ногу стрельнул кривым софтом. P>Телепатия вас подводит, как и всегда. ~/.local/bin — к этому фолдеру я не имею никакого отношения.
Ставишь софт нестандартный. Питон какой-нибудь с user-only зависимостями. Впрочем, ~/.local/bin должен быть в конце PATH и изменять поведение системных тулзов не может.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Pzz>>Ну действительно, не дело это, когда выбор запускаемой программы зависит от текущей директории. _>А то, что он от PATH зависит, не смущает?
Те кто хочет запускать из текущей директории всегда могут сделать export PATH=$PATH:. так что это более универсальное поведение чем захардкоженный поиск в curdir
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Те кто хочет запускать из текущей директории всегда могут сделать export PATH=$PATH:. так что это более универсальное поведение чем захардкоженный поиск в curdir
скажем некоторые софтины используют zip в качестве проектного файла. Киданул в ~/ , распаковал, работаешь. А если подложить тот самый скриптец, то появятся весьма интересные последствия.
N>"Киданул в хомяк" это пять. Косяков.
Что именно вас смущает?
P>>Именно — такие файлы архиватору тоже нельзя давать менять. N>Осталось найти умный ИИ, который отделит архиватор от прочих приложений.
Какой еще ИИ? Нужен апи инсталяции и пакетный менеджер, который его использует. Все остальные автоматически обламываются.
P>>Более того, само наличие таких файлов в линукс говорит о том, что это каменный век. N>Ага, любая кастомизация тогда это каменный век.
У вас похоже кастомизация и .bashrc эквивалентны. На самом деле это не так.
P>>В свое время на винде ровно так же и рассуждали. А потом пришлось затыкать именно эти дыры. Сейчас трояны это денежный бизнес.
N>Только почему-то эти дырозащиты в принципе не работают в той схеме, как они задуманы, а трояны спокойно себе гуляют вдоль и поперёк.
Здравствуйте, ·, Вы писали:
P>>Про пакетный менеджер или инсталятор вы ничего не слышали, правильно понимаю? ·>Про который из них? Их как грязи, даже в винде. Так как операционка будет определять менеджер это или архиватор? Особенно с учётом того, что менеджер в своём составе может иметь тот же архиватор.
Вы там из 90х пишете?
В линуксе нет внятного апи инсталяции, пакетные менеджеры это лебедь рак да щука.
Поскольку пакетный менеджер — часть операционки, он имеет права создавать выполняемые файлы. Архиватор — юзерская программа, по дефолту таких прав не имеет, и апи иснталяции вызывать не сможет.
P>>И затыкали дыру именно по причине троянов, а не просто так, ради прикола ·>Угу, ичхз от троянов это практически не спасает. Потому что — ну кто на эти варнинги смотрит?!
Какие еще варнинги? Вам показывается модальный бокс. Что бы запустить файл, нужно или отключить эту фичу, или обратить внимание, согласиться с последствиям и нажать Run anyway.
Здравствуйте, Conductor, Вы писали:
P>>Цитирую себя P>>"Сама идея архиватором распаковывать выполняемые файлы, скрипты итд, сильно порочная. Эдакий кастомный вариант инсталяции. На таких вот полу-инсталяторах в свое время жило не одно поколение троянов в Виндовс."
C>И? Кто мешает всобачить зловреда в инсталлятор, который по сути и есть архив? Реальная защита что с архивом, что с инсталлятором одинаковая и она суть организационные меры
Архив это просто какой то набор файлов, вы вспотеете подписывать такое. Инсталятор — запросто. А вот архив выбирают для обмена произвольными файлами на все случаи жизни. Например — кидаете в ~/ файл проекта и распаковываете, наблюдаете последствия. Рано или поздно ктото да распакует архив не туда.
Поскольку юзеров на линукс меньше 1%, и неоптных юзеров там вообще около нуля, то это страхует гораздо лучше — система сломается быстрее.
Запрет на инсталяцию-кастомзацию посредством архиватора это и есть часть организационных мер. Это гораздо проще, чем требовать подписи любых архивов. Подпись вашего соседа Васи, который заархивировал свой проект вас не спасет.
Здравствуйте, ·, Вы писали:
P>>Телепатия вас подводит, как и всегда. ~/.local/bin — к этому фолдеру я не имею никакого отношения. ·>Ставишь софт нестандартный. Питон какой-нибудь с user-only зависимостями. Впрочем, ~/.local/bin должен быть в конце PATH и изменять поведение системных тулзов не может.
У вас по прежнему какая то телепатия. Как должно — неинтересно, это и ежу понятно. Я вам привожу пример того, как может быть. Вот этот фолдер у меня прямо с инталяции, я его обнаружил когда искал место куда подкидывать свои скрипты.
Здравствуйте, Pauel, Вы писали:
P>Давно уже в винде — запускаешь скачаный файл
А, так это не винда, это браузер ставит метку в alt stream ...:Zone.Identifier
Если файл попал на машину НЕ через браузер — системе об этом ничего не известно.
Здравствуйте, ·, Вы писали:
·>И именно это и будет написано в инструкции как установить софтинку с трояном. Это не средство безопасности. Это костыль чтобы можно было разводить идиотов, что наша операционка супербезопасная, у нас же есть варнинги! Это уже с ActiveX и прочими макросами проходили, а воз и ныне там.
Не, ну если мы уж начинаем допускать совсем конченых идиотов, то они и sudo rm -rf / сделают, если попросить
Здравствуйте, Pauel, Вы писали:
P>скажем некоторые софтины используют zip в качестве проектного файла. Киданул в ~/ , распаковал, работаешь. А если подложить тот самый скриптец, то появятся весьма интересные последствия. N>>"Киданул в хомяк" это пять. Косяков. P>Что именно вас смущает?
При минимальном уровне понимания такое не делается и не рекомендуется.
Программы, которым нужно иметь своё объёмное обеспечение, требуют своего подкаталога.
Если же какая-то начинает очень активно гадить... ты знаешь где /dev/null.
P>>>Именно — такие файлы архиватору тоже нельзя давать менять. N>>Осталось найти умный ИИ, который отделит архиватор от прочих приложений. P>Какой еще ИИ? Нужен апи инсталяции и пакетный менеджер, который его использует. Все остальные автоматически обламываются.
И после этого пользователь вообще не сможет что-то исполнять не разрешённое в ЦК.
P>>>Более того, само наличие таких файлов в линукс говорит о том, что это каменный век. N>>Ага, любая кастомизация тогда это каменный век. P>У вас похоже кастомизация и .bashrc эквивалентны.
Интересно, откуда такой вывод.
P> На самом деле это не так.
На каком шаге движения к тьюринг-полному конфигу следует остановиться, и почему?
P>>>В свое время на винде ровно так же и рассуждали. А потом пришлось затыкать именно эти дыры. Сейчас трояны это денежный бизнес.
N>>Только почему-то эти дырозащиты в принципе не работают в той схеме, как они задуманы, а трояны спокойно себе гуляют вдоль и поперёк.
P>Приведите пример, где чего не работает.
CVE за пару последних лет. Или ваш неполучившийся анекдот про защиту от запуска скачанных файлов.
Здравствуйте, netch80, Вы писали:
P>>Что именно вас смущает?
N>При минимальном уровне понимания такое не делается и не рекомендуется. N>Программы, которым нужно иметь своё объёмное обеспечение, требуют своего подкаталога.
Такое гарантировано решается ограничением записи в ~/ А иначе получаем тот самый человеческий фактор
P>>Какой еще ИИ? Нужен апи инсталяции и пакетный менеджер, который его использует. Все остальные автоматически обламываются.
N>>>Ага, любая кастомизация тогда это каменный век. P>>У вас похоже кастомизация и .bashrc эквивалентны.
N>Интересно, откуда такой вывод.
Вы приравняли "любая кастомизация" к наличию .bashrc и подобных файлов в ~/
N>На каком шаге движения к тьюринг-полному конфигу следует остановиться, и почему?
Нужно всего лишь ограничивать доступ к конфигам, а не фичи в самих конфигах.
P>>Приведите пример, где чего не работает.
N>CVE за пару последних лет. Или ваш неполучившийся анекдот про защиту от запуска скачанных файлов.
Здравствуйте, Pauel, Вы писали:
N>>При минимальном уровне понимания такое не делается и не рекомендуется. N>>Программы, которым нужно иметь своё объёмное обеспечение, требуют своего подкаталога.
P>Такое гарантировано решается ограничением записи в ~/ А иначе получаем тот самый человеческий фактор
А мы его всегда получаем, но можем в более скрытой форме.
P>>>Какой еще ИИ? Нужен апи инсталяции и пакетный менеджер, который его использует. Все остальные автоматически обламываются.
N>>>>Ага, любая кастомизация тогда это каменный век. P>>>У вас похоже кастомизация и .bashrc эквивалентны.
N>>Интересно, откуда такой вывод.
P>Вы приравняли "любая кастомизация" к наличию .bashrc и подобных файлов в ~/
Откуда вывод про приравнивание?
N>>На каком шаге движения к тьюринг-полному конфигу следует остановиться, и почему?
P>Нужно всего лишь ограничивать доступ к конфигам, а не фичи в самих конфигах.
"А судьи кто"? Кто будет решать, что допускать в конфигах, а что нет?
P>>>Приведите пример, где чего не работает.
N>>CVE за пару последних лет. Или ваш неполучившийся анекдот про защиту от запуска скачанных файлов.
P>Вам нечего сказать.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, ·, Вы писали:
CC>·>И именно это и будет написано в инструкции как установить софтинку с трояном. Это не средство безопасности. Это костыль чтобы можно было разводить идиотов, что наша операционка супербезопасная, у нас же есть варнинги! Это уже с ActiveX и прочими макросами проходили, а воз и ныне там.
CC>Не, ну если мы уж начинаем допускать совсем конченых идиотов, то они и sudo rm -rf / сделают, если попросить
Ну так потому ты в андроиде, в (AFAIH) макоси и ещё много где не можешь стереть систему и критические части.
А у компа не можешь без отвёртки и паяльника стереть BIOS или вписать туда что-то левое.
Но это не может быть распространено на уровень личной конфигурации без фатального(*) нарушения прав пользователя.
(*) Есть эквивалент слова crucial? Fatal слишком сильно, а critical чуть в сторону.
Здравствуйте, netch80, Вы писали:
N>>>Программы, которым нужно иметь своё объёмное обеспечение, требуют своего подкаталога.
P>>Такое гарантировано решается ограничением записи в ~/ А иначе получаем тот самый человеческий фактор
N>А мы его всегда получаем, но можем в более скрытой форме.
Именно. Все трояны-вирусы в той или иной степени именно на этом и существуют. Потому и закрывают те или иные возможности, которыми легко злоупотребить.
P>>Вы приравняли "любая кастомизация" к наличию .bashrc и подобных файлов в ~/
N>Откуда вывод про приравнивание?
А вы себя читайте — началось про bashrc, а потом вы выдали "любая кастомизация тогда это каменный век"
На мой взгляд с самой кастомизацией все в порядке, а вот кастомизация через файлы в ~/ и архиваторы это конечно же отстой
P>>Нужно всего лишь ограничивать доступ к конфигам, а не фичи в самих конфигах.
N>"А судьи кто"? Кто будет решать, что допускать в конфигах, а что нет?
Еще раз и медленно — ограничивать нужно доступ к конфигам. В самих конфигах пишите что вам вздумается. Если к ним нет левого доступа, то всё в порядке.
Здравствуйте, ·, Вы писали:
P>>Вы там из 90х пишете? P>>В линуксе нет внятного апи инсталяции, пакетные менеджеры это лебедь рак да щука. ·>MSI??! Спасибо, не надо, сами такое кушайте.
Разве я сказал про msi? Это у вас всё еще телепатия булькает.
P>>Поскольку пакетный менеджер — часть операционки, он имеет права создавать выполняемые файлы. ·>Ты конкретно говори, с деталями. Как операционка определяет, что пакетный менеджер, а что не очень? Предлагаешь ещё один атрибут для файлов ввести или что?
Пакетный менеджер должен быть сервисом операционки, а не просто программой которая чтото куда то копирует.
P>>Архиватор — юзерская программа, по дефолту таких прав не имеет, и апи иснталяции вызывать не сможет. ·>Юзерам иногда надо иметь возможность ставить свои проги, без прав админа.
Вот-вот — у вас архиватор ассоциируется с инсталяцией софта. Весего то нужно дать права юзеру инсталировать софт. Его собственный софт ставится в его же хом. Для этого достаточно пакетного менеджера.
P>>Вам показывается модальный бокс. Что бы запустить файл, нужно или отключить эту фичу, или обратить внимание, согласиться с последствиям и нажать Run anyway. ·>И именно это и будет написано в инструкции как установить софтинку с трояном. Это не средство безопасности.
Разумеется. При этом научить юзеров ориентироваться по таким вот красным флажкам гораздо легче, чем дать им нужный уровень компьютерной грамотности.
На примере — вы вроде бы грамотный пользователь, но всё еще уверенно путаете архиватор и инсталятор.
Здравствуйте, Pauel, Вы писали:
P>>>Вы там из 90х пишете? P>>>В линуксе нет внятного апи инсталяции, пакетные менеджеры это лебедь рак да щука. P>·>MSI??! Спасибо, не надо, сами такое кушайте. P>Разве я сказал про msi? Это у вас всё еще телепатия булькает.
Это апи инсталляции. Или оно невнятное?
P>>>Поскольку пакетный менеджер — часть операционки, он имеет права создавать выполняемые файлы. P>·>Ты конкретно говори, с деталями. Как операционка определяет, что пакетный менеджер, а что не очень? Предлагаешь ещё один атрибут для файлов ввести или что? P>Пакетный менеджер должен быть сервисом операционки, а не просто программой которая чтото куда то копирует.
Ты конкретно говори, с деталями. Что такое сервис операционки и чем он отличается от просто программы с технической точки зрения? Что запретит сделать программу, которая что-то копирует неким сервисом операционки?
Компилятор С++, например, тоже должен быть сервисом операционки? Или ему не положено создавать выполняемые файлы?
P>>>Архиватор — юзерская программа, по дефолту таких прав не имеет, и апи иснталяции вызывать не сможет. P>·>Юзерам иногда надо иметь возможность ставить свои проги, без прав админа. P>Вот-вот — у вас архиватор ассоциируется с инсталяцией софта. Весего то нужно дать права юзеру инсталировать софт. Его собственный софт ставится в его же хом. Для этого достаточно пакетного менеджера.
И что, например, запретит поставить через пакетный менеджер например python и потом гонять "c:\bin\python Downloads\troyan.py"?
P>>>Вам показывается модальный бокс. Что бы запустить файл, нужно или отключить эту фичу, или обратить внимание, согласиться с последствиям и нажать Run anyway. P>·>И именно это и будет написано в инструкции как установить софтинку с трояном. Это не средство безопасности. P>Разумеется. При этом научить юзеров ориентироваться по таким вот красным флажкам гораздо легче, чем дать им нужный уровень компьютерной грамотности.
Т.е. опыт ActiveX и т.п. ничему не научил.
P>На примере — вы вроде бы грамотный пользователь, но всё еще уверенно путаете архиватор и инсталятор.
Это ваши голоса в голове путают.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
P>>·>MSI??! Спасибо, не надо, сами такое кушайте. P>>Разве я сказал про msi? Это у вас всё еще телепатия булькает. ·>Это апи инсталляции. Или оно невнятное?
Невнятное. Там чорт ногу сломит
·>Ты конкретно говори, с деталями. Что такое сервис операционки и чем он отличается от просто программы с технической точки зрения? Что запретит сделать программу, которая что-то копирует неким сервисом операционки?
Может вам сразу пулл реквест выдать? С технической точки зрения сервис требует особых прав на инсталяцию и запуск. Вы должны явно указать, что исталируете сервис, а не просто так, мимоходом.
·>Компилятор С++, например, тоже должен быть сервисом операционки? Или ему не положено создавать выполняемые файлы?
Пусть создаёт в разрешенном фолдере.
P>>Вот-вот — у вас архиватор ассоциируется с инсталяцией софта. Весего то нужно дать права юзеру инсталировать софт. Его собственный софт ставится в его же хом. Для этого достаточно пакетного менеджера. ·>И что, например, запретит поставить через пакетный менеджер например python и потом гонять "c:\bin\python Downloads\troyan.py"?
Мы рассматриваем простой кейс, когда троян подменяет часто используемый скрипт или команду итд.
P>>Разумеется. При этом научить юзеров ориентироваться по таким вот красным флажкам гораздо легче, чем дать им нужный уровень компьютерной грамотности. ·>Т.е. опыт ActiveX и т.п. ничему не научил.
Здравствуйте, Pauel, Вы писали:
P>>>Разве я сказал про msi? Это у вас всё еще телепатия булькает. P>·>Это апи инсталляции. Или оно невнятное? P>Невнятное. Там чорт ногу сломит
А, ну так я тоже за все хорошие api и против всех плохих. И вообще за мир во всём мире.
P>·>Ты конкретно говори, с деталями. Что такое сервис операционки и чем он отличается от просто программы с технической точки зрения? Что запретит сделать программу, которая что-то копирует неким сервисом операционки? P>Может вам сразу пулл реквест выдать? С технической точки зрения сервис требует особых прав на инсталяцию и запуск. Вы должны явно указать, что исталируете сервис, а не просто так, мимоходом.
Ясно. Надо просто сделать всё правильно и чтобы оно хорошо работало. Согласен.
P>·>Компилятор С++, например, тоже должен быть сервисом операционки? Или ему не положено создавать выполняемые файлы? P>Пусть создаёт в разрешенном фолдере.
Я, как пользователь, смогу добавить этот разрешенный фолдер в path? Или просто сразу разрешить создавать в ~/.local/bin? Если да, то чем это отличается от типичного архиватора, где я, как пользователь, должен указывать фолдер куда распаковать?
P>>>Вот-вот — у вас архиватор ассоциируется с инсталяцией софта. Весего то нужно дать права юзеру инсталировать софт. Его собственный софт ставится в его же хом. Для этого достаточно пакетного менеджера. P>·>И что, например, запретит поставить через пакетный менеджер например python и потом гонять "c:\bin\python Downloads\troyan.py"? P>Мы рассматриваем простой кейс, когда троян подменяет часто используемый скрипт или команду итд.
Я к тому, что подменять можно не только напрямую исполняемый операционкой файл, но и некий скрипт, исполняемый другой программой.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, CreatorCray, Вы писали:
P>>Давно уже в винде — запускаешь скачаный файл CC>А, так это не винда, это браузер ставит метку в alt stream ...:Zone.Identifier CC>Если файл попал на машину НЕ через браузер — системе об этом ничего не известно.
Решето, конечно. Тем не менее это закрывает наиболее частый кейс, когда скачал файлик и тут же попробовал его запустить.
Здравствуйте, ·, Вы писали:
·>Я, как пользователь, смогу добавить этот разрешенный фолдер в path? Или просто сразу разрешить создавать в ~/.local/bin? Если да, то чем это отличается от типичного архиватора, где я, как пользователь, должен указывать фолдер куда распаковать?
Вы, как пользователь, можете даже в унитаз ноутбук слить. Важно закрыть ненамеренные способы создания дыр. Здесь нет конечного готового решения — как только троянописатели придумают многоходовочку, нужно и там подшаманить.
P>>·>И что, например, запретит поставить через пакетный менеджер например python и потом гонять "c:\bin\python Downloads\troyan.py"? P>>Мы рассматриваем простой кейс, когда троян подменяет часто используемый скрипт или команду итд. ·>Я к тому, что подменять можно не только напрямую исполняемый операционкой файл, но и некий скрипт, исполняемый другой программой.
Вы изобрели один из давно известных способов внедрения у троянов. С архивами абсолютной гарантии никто не даст — всегда можно найти уязвимость, основываясь на привычках пользователей.
Здравствуйте, Pauel, Вы писали:
P>·>Я, как пользователь, смогу добавить этот разрешенный фолдер в path? Или просто сразу разрешить создавать в ~/.local/bin? Если да, то чем это отличается от типичного архиватора, где я, как пользователь, должен указывать фолдер куда распаковать? P>Вы, как пользователь, можете даже в унитаз ноутбук слить. Важно закрыть ненамеренные способы создания дыр. Здесь нет конечного готового решения — как только троянописатели придумают многоходовочку, нужно и там подшаманить.
Ты предложил решение "Пусть создаёт в разрешенном фолдере", я задал пару уточняющих вопросов как это вообще может работать, но по твоим же словам это просто сливание в унитаз ноутбука. Ну ладно, договорились, спорить тут не с чем. Просто прими как данное, что не все хотят свои ноутбуки в унитаз сливать.
P>>>Мы рассматриваем простой кейс, когда троян подменяет часто используемый скрипт или команду итд. P>·>Я к тому, что подменять можно не только напрямую исполняемый операционкой файл, но и некий скрипт, исполняемый другой программой. P>Вы изобрели один из давно известных способов внедрения у троянов. С архивами абсолютной гарантии никто не даст — всегда можно найти уязвимость, основываясь на привычках пользователей.
Не изобрёл, просто напомнил, что предлагаемые тобой способы сливания в унитаз ноутбука — ерунда на постном масле.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pzz, Вы писали:
Pzz>Ну вот ты выкачиваешь foo.tar.gz. Распаковываешь. Заходишь внутрь.
Зачем заходить внутрь?
Pzz>А ты, такой, говоришь ls стоя в этой внутренней директории, вынутой из архива. Ну, чтобы список файлов посмотреть. А потом уже всякое такое говоришь, уже не компьютеру, а ртом, чего я даже воображать не буду, чего говоришь.
Сколько раз такое случалось на практике?
Ну серьёзно!
Вот вы скачали foo.tar.gz.
Распаковали, зашли внутрь.
Теперь вам надо собрать foo.
Делаете ./configure
Затем вызываете make
А в файле Makefile
где-то затесалясь команда, ну... скажем... rm -rf ../../
И?
Как вы, параноики, от этого защищаетесь?
Особенно если учесть, что следующая естественная команда, это sudo make install...
Здравствуйте, ·, Вы писали:
P>>·>Я, как пользователь, смогу добавить этот разрешенный фолдер в path? Или просто сразу разрешить создавать в ~/.local/bin? Если да, то чем это отличается от типичного архиватора, где я, как пользователь, должен указывать фолдер куда распаковать? P>>Вы, как пользователь, можете даже в унитаз ноутбук слить. Важно закрыть ненамеренные способы создания дыр. Здесь нет конечного готового решения — как только троянописатели придумают многоходовочку, нужно и там подшаманить. ·>Ты предложил решение "Пусть создаёт в разрешенном фолдере", я задал пару уточняющих вопросов как это вообще может работать, но по твоим же словам это просто сливание в унитаз ноутбука.
У вас все еще булькает телепатия. "Я, как пользователь, смогу добавить этот разрешенный фолдер в path" — если вы это делаете случайно, непреднамеренно, то это дыра которая рано или поздно сработает. А если вы делаете это сознательно, то это и есть эквивалент ноутбука в унитазе.
Вам бы пореже телепатией пользоваться. Не существует никаких способов избавить вас от намеренных действий по созданию дыры, поломки, итд. Речь всегда про ограничение непреднамеренных опасных действий.
Т.е. в сумме вы утверждаете чтото навроде "защита херня, потому что юзер может взять да отключить защиту". Это я вам пример привел, что бы понятнее было, какой вы бред несете.
Здравствуйте, Pauel, Вы писали:
P>·>Ты предложил решение "Пусть создаёт в разрешенном фолдере", я задал пару уточняющих вопросов как это вообще может работать, но по твоим же словам это просто сливание в унитаз ноутбука. P>У вас все еще булькает телепатия. "Я, как пользователь, смогу добавить этот разрешенный фолдер в path" — если вы это делаете случайно, непреднамеренно, то это дыра которая рано или поздно сработает. А если вы делаете это сознательно, то это и есть эквивалент ноутбука в унитазе. P>Вам бы пореже телепатией пользоваться.
Чем изменение path случайнее, непреднамереннее распаковки архива с указанием bin?
Другими словами, почему ты считаешь, что разрешать фолдеры компилятору — сознательный акт, а распаковка архивов в явно указанный фолдер — непреднамеренный?
Мы вроде сабж обсуждаем. Именно он и делает хоть какую-то защиту. Возможность создать (неважно каким способом) файл в любой случайной директории и случайно его выполнить потому что его имя совпало с какой-нибудь системной командой — это огромная дыра в безопасности. Наконец-то её закрыли, всего несколько десятков лет прошло. Специальные сервисы, магические API, веб-метки — это какой-то майкрософт головного мозга.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
P>>Вам бы пореже телепатией пользоваться. ·>Чем изменение path случайнее, непреднамереннее распаковки архива с указанием bin?
Расскажите, как вы случайно, не глядя, чего то добавите в path. Подробнее. Вы привели пример противоположного действия — сознательно вписать в path тот или иной фолдер.
Это и есть тот случай — защита фигня, потому что её можно отключить по инструкции.
·>Другими словами, почему ты считаешь, что разрешать фолдеры компилятору — сознательный акт, а распаковка архивов в явно указанный фолдер — непреднамеренный?
Вас похоже телепатия за яйца крепко держит.
Если юзер хочет заниматься компиляцией, он обязан разрешить тот или иной фолдер. Какой разрешит — такой и эффект будет. Разрешит / или ~/ — сам себе буратино.
Распаковка архивов — ровно то же. И там, и там по дефолту / и ~/ должны быть закрыты. Тогда непреднамеренные действия будут ограничены.
·>Мы вроде сабж обсуждаем. Именно он и делает хоть какую-то защиту. Возможность создать (неважно каким способом) файл в любой случайной директории и случайно его выполнить потому что его имя совпало с какой-нибудь системной командой — это огромная дыра в безопасности.
А кто спорит, что это дыра? Я пишу том, что есть и другая дыра — архиваторы, т.к. их используют как замену пакетным менеджерам. Например у вас есть такое же видение, что архиватор и инсталятор это одно и то же.
Здравствуйте, Pauel, Вы писали:
P>>>Вам бы пореже телепатией пользоваться. P>·>Чем изменение path случайнее, непреднамереннее распаковки архива с указанием bin? P>Расскажите, как вы случайно, не глядя, чего то добавите в path. Подробнее.
В линухах — никак. О том и речь. В винде — до сабжа — запросто. И трояны есть именно в винде, несмотря на сервисы, api иснталляторов, веб-метки и прочий бред.
P>Вы привели пример противоположного действия — сознательно вписать в path тот или иной фолдер.
Это что уже десятилетия существует в линухах без всяких предложенных тобою как новшество "разрешенных фолдеров".
P>·>Другими словами, почему ты считаешь, что разрешать фолдеры компилятору — сознательный акт, а распаковка архивов в явно указанный фолдер — непреднамеренный? P> Вас похоже телепатия за яйца крепко держит. P>Если юзер хочет заниматься компиляцией, он обязан разрешить тот или иной фолдер. Какой разрешит — такой и эффект будет. Разрешит / или ~/ — сам себе буратино. P>Распаковка архивов — ровно то же. И там, и там по дефолту / и ~/ должны быть закрыты. Тогда непреднамеренные действия будут ограничены.
/ и так уж в линухах закрыт, с рождения. ~ закрывать — бред и никакой безопасности не добавит, т.к. ~ в path ставят куда надо, а не куда попало.
P>·>Мы вроде сабж обсуждаем. Именно он и делает хоть какую-то защиту. Возможность создать (неважно каким способом) файл в любой случайной директории и случайно его выполнить потому что его имя совпало с какой-нибудь системной командой — это огромная дыра в безопасности. P>А кто спорит, что это дыра? Я пишу том, что есть и другая дыра — архиваторы, т.к. их используют как замену пакетным менеджерам. Например у вас есть такое же видение, что архиватор и инсталятор это одно и то же.
Верно, одно и то же с т.з. безопасности. Потому что совершенно неважно какая именно прога создаёт файлы.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
BFE>Использовать в 21-ом веке терминал для файловых операций, это всё равно, что смотреть на графический экран через замочную скважину. Оно, конечно, можно, но страшно неэффективно не неудобно.
grep/tail/less для многогиговых файлов как? Особенно "tail -f" или аналоги.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
P>>·>Чем изменение path случайнее, непреднамереннее распаковки архива с указанием bin? P>>Расскажите, как вы случайно, не глядя, чего то добавите в path. Подробнее. ·>В линухах — никак. О том и речь. В винде — до сабжа — запросто.
Подробнее пожалуйста. Как вы винде добавите чтото случайно в path.
> И трояны есть именно в винде, несмотря на сервисы, api иснталляторов, веб-метки и прочий бред.
Потому, что система крайне популярная. Когда не было тех самых сервисов итд — было сильно хуже.
P>>Распаковка архивов — ровно то же. И там, и там по дефолту / и ~/ должны быть закрыты. Тогда непреднамеренные действия будут ограничены. ·>/ и так уж в линухах закрыт, с рождения. ~ закрывать — бред и никакой безопасности не добавит, т.к. ~ в path ставят куда надо, а не куда попало.
Наоборот, линукс от рождения открыт. В свое время нашлось чудовищно много энтузиастов, которые запускали однострочник на перле, в десяток символов-закорючек, который успешно чистил рут.
Потом уже начали создавать обычных администраторов, и тем не менее, регулярно встречается плак по самым разным поводам.
P>>А кто спорит, что это дыра? Я пишу том, что есть и другая дыра — архиваторы, т.к. их используют как замену пакетным менеджерам. Например у вас есть такое же видение, что архиватор и инсталятор это одно и то же. ·>Верно, одно и то же с т.з. безопасности. Потому что совершенно неважно какая именно прога создаёт файлы.
В данный момент так и есть. А я говорю что можно сделать иначе, для чего понадобится внятное апи инсталяции и пакетный менеджер как сервис ос, что в данный момент отсутствует.
Здравствуйте, Pauel, Вы писали:
P>·>В линухах — никак. О том и речь. В винде — до сабжа — запросто. P>Подробнее пожалуйста. Как вы винде добавите чтото случайно в path.
Текущая директория в path, притом с высшим приоритетом. Любой файл в текущей директории выполнится если совпадёт имя с системной тулзой. Притом с любым расширением — и bat и exe и vbs т.п. — т.е. готовы к выполнению сразу куча запускалок. Достаточно дыры в любой из них — троян готов.
>> И трояны есть именно в винде, несмотря на сервисы, api иснталляторов, веб-метки и прочий бред. P>Потому, что система крайне популярная. Когда не было тех самых сервисов итд — было сильно хуже.
Могу смело предположить, что линухов в мире больше, в каждой кофеварке. А если говорить о пользовательских устройствах и неквалифицированных пользователях, то маки тоже ужасно популярны. Однако трояны Win-only, даже часто под wine работать не хотят.
P>>>Распаковка архивов — ровно то же. И там, и там по дефолту / и ~/ должны быть закрыты. Тогда непреднамеренные действия будут ограничены. P>·>/ и так уж в линухах закрыт, с рождения. ~ закрывать — бред и никакой безопасности не добавит, т.к. ~ в path ставят куда надо, а не куда попало. P>Наоборот, линукс от рождения открыт. В свое время нашлось чудовищно много энтузиастов, которые запускали однострочник на перле, в десяток символов-закорючек, который успешно чистил рут.
А винда кишела вирусами и падала сама, без всяких символов-закорючек, могла жить только в локалке, за линуховым фаерволом.
P>Потом уже начали создавать обычных администраторов, и тем не менее, регулярно встречается плак по самым разным поводам.
Каких администраторов? sudoers что-ли?
P>·>Верно, одно и то же с т.з. безопасности. Потому что совершенно неважно какая именно прога создаёт файлы. P>В данный момент так и есть. А я говорю что можно сделать иначе, для чего понадобится внятное апи инсталяции и пакетный менеджер как сервис ос, что в данный момент отсутствует.
Конечно можно, никто не запрещает, у нас свободная страна! Но ты не говоришь как, полагаю, ты патент готовишь и скоро все проблемы человечества будут решены.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Текущая директория в path, притом с высшим приоритетом.
Вы так торопитесь строчить, что никак не заметите, что это уже пофиксили. Загляните в название темы, если вам все еще непонятно.
·>Могу смело предположить, что линухов в мире больше, в каждой кофеварке. А если говорить о пользовательских устройствах и неквалифицированных пользователях, то маки тоже ужасно популярны. Однако трояны Win-only, даже часто под wine работать не хотят.
Трояны давно освоили андроид, айфон и макось. Вы продолжаете писать из 90х
P>>Наоборот, линукс от рождения открыт. В свое время нашлось чудовищно много энтузиастов, которые запускали однострочник на перле, в десяток символов-закорючек, который успешно чистил рут. ·>А винда кишела вирусами и падала сама, без всяких символов-закорючек, могла жить только в локалке, за линуховым фаерволом.
Падала. Последние 10 лет всё совершенно иначе. У меня вот свежий линукс на хорошем линуксовом железе падает за месяц чаще, чем винда за год.
P>>Потом уже начали создавать обычных администраторов, и тем не менее, регулярно встречается плак по самым разным поводам. ·>Каких администраторов? sudoers что-ли?
Дурацкий вопрос — создаёте пользователя, добавляете в группу администраторов. Тем не менее ктото сидит все еще под рутом, ктото под su, ктото sudo поднастроил так, что никакого пароля не требует.
Здравствуйте, Pauel, Вы писали:
P>·>Текущая директория в path, притом с высшим приоритетом. P>Вы так торопитесь строчить, что никак не заметите, что это уже пофиксили. Загляните в название темы, если вам все еще непонятно.
Так и я о том же. И накой эти все твои сервисы, разрешенные фолдеров и api инсталляции-то? PATH это и есть список разрешенных фолдеров по сути.
P>·>Могу смело предположить, что линухов в мире больше, в каждой кофеварке. А если говорить о пользовательских устройствах и неквалифицированных пользователях, то маки тоже ужасно популярны. Однако трояны Win-only, даже часто под wine работать не хотят. P>Трояны давно освоили андроид, айфон и макось. Вы продолжаете писать из 90х
Я WannaCry о твоих познаниях. ZeroAccess и т.п. это совсем не 90е. Вирусня в андроиде/етс существует на уровне легенд.
P>>>Потом уже начали создавать обычных администраторов, и тем не менее, регулярно встречается плак по самым разным поводам. P>·>Каких администраторов? sudoers что-ли? P>Дурацкий вопрос — создаёте пользователя, добавляете в группу администраторов. Тем не менее ктото сидит все еще под рутом, ктото под su, ктото sudo поднастроил так, что никакого пароля не требует.
Ну нету никакой группы администраторов в линухах, потому и спрашиваю что имеется в виду. А sudo без пароля вроде требует интерактива, поэтому неясно в чём проблема.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pauel, Вы писали:
P>Еще раз и медленно — ограничивать нужно доступ к конфигам. В самих конфигах пишите что вам вздумается. Если к ним нет левого доступа, то всё в порядке.
Теперь осталось понять, какой доступ левый и как это определить. Только вот тут почему-то и начинаются сложности.
N>>А мы его всегда получаем, но можем в более скрытой форме. P>Именно. Все трояны-вирусы в той или иной степени именно на этом и существуют. Потому и закрывают те или иные возможности, которыми легко злоупотребить.
И вот их обычно закрывают раздельными пользователями и вложенными виртуалками разной степени навороченности — это уже работает — а не мифическими "запретим ставить исполняемость тем, кто сегодня непохож на инсталлятор".
P>>>Вы приравняли "любая кастомизация" к наличию .bashrc и подобных файлов в ~/ N>>Откуда вывод про приравнивание? P>А вы себя читайте — началось про bashrc, а потом вы выдали "любая кастомизация тогда это каменный век"
Здравствуйте, B0FEE664, Вы писали:
BFE>Ну серьёзно! BFE>Вот вы скачали foo.tar.gz. BFE>Распаковали, зашли внутрь. BFE>Теперь вам надо собрать foo. BFE>Делаете ./configure BFE>Затем вызываете make BFE>А в файле Makefile BFE>где-то затесалясь команда, ну... скажем... rm -rf ../../ BFE>И? BFE>Как вы, параноики, от этого защищаетесь? BFE>Особенно если учесть, что следующая естественная команда, это sudo make install...
"Параноики" на это всё смотрят так:
1. Всё что можно вынести в разнообразные вложенные контейнеры и что подвергается хоть малейшему подозрению — уносится туда. Из контейнера выползти наружу это уже редчайшее событие, раз на десять лет. В зависимости от типа и настроек контейнера можно виртуализировать и ограничивать в ресурсах всё. Уровень контейнеризации плавает от, грубо говоря, докера внутри virtualbox-системы (тут может быть HyperV, Xen, VMWare тысяча других слов) до просто virtualbox, docker (с аналогами podman, containerd, прочими) и вплоть до простого chroot.
Вон в соседнем письме рекомендовали firejail. Я такого не видел, я ленивый и скорее в докер впихну
Ещё одно преимущество контейнеров, хотя бы в стиле докера — что можно после установки такой тулзы сравнить файловые деревья и найти все изменения, что не положены.
2. Если есть немного побольше доверия к авторам — типа они не злонамеренные, но могут просто забыть что-то важное — средства типа checkinstall. В Debian чуть ли не с его основания были варианты отдать управление make install, но через перехватчик, который сам соберёт список установленных файлов и изменений в существующих файлах. Потом этот лог изменений используется для пакетирования. Результат пакетирования можно потом снести просто удалением кастомного пакета.
Но вообще это всё описывает редчайшую на сейчас ситуацию. Обычно или даются пакеты под целевую ОС, или средство целиком существует в своём каталоге (может потребовать дистрибутивных пакетов от ОС). И вот тогда его можно хоть в контейнер, хоть под ограничитель операций, хоть доверяя — ничего не трогать. Например, conda — я её авторам вполне доверяю, чтобы она стала в свой каталог и работала.
А вот "естественность" sudo make install — это реально мифы не менее чем 20-летней давности, если не 30-летней. Slackware стала уходить из популярности, кажется, году в 96-м или около того, окончательно задавленная RH & Debian? Ну вот с тех времён у тебя воспоминания...
Здравствуйте, Pauel, Вы писали:
P>Архив это просто какой то набор файлов, вы вспотеете подписывать такое. Инсталятор — запросто.
Из-за чего вспотею, контрольную сумму файла архива посчитать? Ну и в текущих условиях (для России и Беларуси) что более вероятно: получить зловреда в архиве от соседа Васи или внутри подписасанного по всем правилам инсталлятора от, скажем, микрософта?
P>А вот архив выбирают для обмена произвольными файлами на все случаи жизни. Например — кидаете в ~/ файл проекта и распаковываете, наблюдаете последствия. Рано или поздно ктото да распакует архив не туда.
Создать подкаталог и там распаковать — что-то мешает? Так тогда это бардак в голове, а не в технических средствах. А ещё кто-нибудь ногу себе топором может отфигачить или с крыши сигануть — давайте топоры и крыши запретим. Откровенно задолбал патернализм из всех щелей, тотальное поощрение инфантильности и, как следствие, безответственности. Складывается устойчивое ощущение, что слово "ответственность" стало уже ругательным.
P>Поскольку юзеров на линукс меньше 1%, и неоптных юзеров там вообще около нуля, то это страхует гораздо лучше — система сломается быстрее.
Я не знаю что там и как сломается и откуда у Вас, коллега, в PATH по умолчанию взялся ~/.local/bin, знаю только, что у меня win7 без переустановки с 2012 года работает и, более того, в этом же виде благополучно переехала внутрь виртуалки, когда в 2020 я наконец-то собрался полностью переехать на linux как основную ОС. И, кстати, за три года ни одного зависания linux не было, хотя извращался я над ним за это время от души.
P>Подпись вашего соседа Васи, который заархивировал свой проект вас не спасет.
Если Вася прислал мне архив, подпись которого корректна, но при этом содержит что-то нехорошее, то Вася очень рискует "получить в бубен". Варианты "бубна" достаточно разнообразны: от собственно "в бубен" до привлечения к решению проблемы правоохранительных органов.
Здравствуйте, netch80, Вы писали:
N>А вот "естественность" sudo make install — это реально мифы не менее чем 20-летней давности, если не 30-летней. Slackware стала уходить из популярности, кажется, году в 96-м или около того, окончательно задавленная RH & Debian? Ну вот с тех времён у тебя воспоминания...
Я в Debian эту команду выполнял в этом году.
Может я чего-то не знаю, но как иначе поставить свежую версию git в систему?
Здравствуйте, maxkar, Вы писали:
BFE>>Как вы, параноики, от этого защищаетесь? M>Параноика вызывали?
Да.
M>Если оно что-то и удалит, то только свою песочницу. Там особо терять нечего.
Разве от сценария описанного здесь
это не спасает? А если спасает, то зачем subj?
BFE>>Особенно если учесть, что следующая естественная команда, это sudo make install... M>Не, это не естественная команда. Следующим идет естественный вопрос: а как я это все буду удалять после установки?
Сносом системы.
Здравствуйте, B0FEE664, Вы писали:
N>>А вот "естественность" sudo make install — это реально мифы не менее чем 20-летней давности, если не 30-летней. Slackware стала уходить из популярности, кажется, году в 96-м или около того, окончательно задавленная RH & Debian? Ну вот с тех времён у тебя воспоминания... BFE> BFE>Я в Debian эту команду выполнял в этом году. BFE>Может я чего-то не знаю, но как иначе поставить свежую версию git в систему?
sudo apt-get install git
Отсюда: https://git-scm.com/download/linux
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, netch80, Вы писали:
N>>А вот "естественность" sudo make install — это реально мифы не менее чем 20-летней давности, если не 30-летней. Slackware стала уходить из популярности, кажется, году в 96-м или около того, окончательно задавленная RH & Debian? Ну вот с тех времён у тебя воспоминания...
BFE> BFE>Я в Debian эту команду выполнял в этом году.
Нет, ты, конечно, можешь это сделать. Технически — ничего не запрещает. Ты можешь вообще всё вручную перекорёжить по сравнению с тем состоянием, что дают пакетные менеджеры. Но зачем?
BFE>Может я чего-то не знаю, но как иначе поставить свежую версию git в систему?
Ну эта... я же всё описал в предыдущем комментарии.
Ты можешь поставить его исключительно в ~/opt/git-$version/ и затем поставить на него симлинк из ~/bin или ~/.local/bin. Если тебе просто ради личного удобства, то так проще и прямее всего. Я себе именно так и сделал.
Ты можешь сделать то же самое в общесистемный /opt/git-$version/ и для этого не надо рута, если заранее дать себе права на каталог. Можешь потом подменить /usr/bin/git на симлинк, если тебе нужен заменить системный git — не знаю, зачем, но предположим, что было нужно.
Но если тебе надо заменить системный git, то единственным правильным способом является собрать пакет из нужной версии и уже средствами пакетного менеджера установить его вместо текущего. А вот эту сборку, если боишься, сделать в контейнере и проверить результат. Это всё значительно легче, чем кажется издалека, команды стандартны и просты. Я делал, мы свой софт пакетировали и ставили через свой сервер.
Если твёрдо хочешь, чтобы всякие апгрейды его не трогали, вызови apt-mark hold.
В общем, повторюсь, Slackware и её подходы давно не в почёте
Здравствуйте, Conductor, Вы писали:
C>Я не знаю что там и как сломается и откуда у Вас, коллега, в PATH по умолчанию взялся ~/.local/bin
В Ubuntu, например, стандартный ~/.bash_profile содержит такие интересные заклинания:
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
PATH="$HOME/.local/bin:$PATH"
fi
А вот в этот каталог ставят свои входные программы несколько источников — например, локально установленные через pip пакеты с программной мордой. Я вот у себя сейчас вижу:
$ ls -l ~/.local/bin/
total 16
-rwxrwxr-x 1 netch netch 209 Dec 6 2022 litecli
-rwxrwxr-x 1 netch netch 205 Jan 14 2022 pysemver
-rwxrwxr-x 1 netch netch 216 Dec 6 2022 sqlformat
-rwxrwxr-x 1 netch netch 209 Dec 6 2022 tabulate
Это всё из pip-пакетов локального юзера, причём из этого списка я сам, кажется, только litecli подключал. Остальные сами подтянулись.
Вот такие чудеса прилетели из новостей пакетного администрирования. Я сам удивился, когда первый раз увидел.
Тут таки лёгкое нарушение ожидаемого. Но не более чем если я на системном уровне ставлю X, который тянет Y, у которого свой управляющий бинарь.
C>Создать подкаталог и там распаковать — что-то мешает?
Pauel считает, что юзер рано или поздно пойдёт распаковывать напрямую в хомяке.
C> Так тогда это бардак в голове, а не в технических средствах. А ещё кто-нибудь ногу себе топором может отфигачить или с крыши сигануть — давайте топоры и крыши запретим. Откровенно задолбал патернализм из всех щелей, тотальное поощрение инфантильности и, как следствие, безответственности. Складывается устойчивое ощущение, что слово "ответственность" стало уже ругательным.
C>Если Вася прислал мне архив, подпись которого корректна, но при этом содержит что-то нехорошее, то Вася очень рискует "получить в бубен". Варианты "бубна" достаточно разнообразны: от собственно "в бубен" до привлечения к решению проблемы правоохранительных органов.
Ну вообще-то есть варианты, типа, это был не Вася...
Здравствуйте, netch80, Вы писали:
P>>Еще раз и медленно — ограничивать нужно доступ к конфигам. В самих конфигах пишите что вам вздумается. Если к ним нет левого доступа, то всё в порядке.
N>Теперь осталось понять, какой доступ левый и как это определить. Только вот тут почему-то и начинаются сложности.
В том то и дело, что с нынешним подходом это крайне проблематично — home это россыпь конфигов и скриптов.
P>>Именно. Все трояны-вирусы в той или иной степени именно на этом и существуют. Потому и закрывают те или иные возможности, которыми легко злоупотребить.
N>И вот их обычно закрывают раздельными пользователями и вложенными виртуалками разной степени навороченности — это уже работает — а не мифическими "запретим ставить исполняемость тем, кто сегодня непохож на инсталлятор".
Этот мифический запрет почему то отлично реализован в Андроиде.
Здравствуйте, netch80, Вы писали:
N>Но если тебе надо заменить системный git, то единственным правильным способом является собрать пакет из нужной версии и уже средствами пакетного менеджера установить его вместо текущего.
Мда...
Тяжело быть параноиком.
Здравствуйте, Pauel, Вы писали:
P>>>Еще раз и медленно — ограничивать нужно доступ к конфигам. В самих конфигах пишите что вам вздумается. Если к ним нет левого доступа, то всё в порядке.
N>>Теперь осталось понять, какой доступ левый и как это определить. Только вот тут почему-то и начинаются сложности.
P>В том то и дело, что с нынешним подходом это крайне проблематично — home это россыпь конфигов и скриптов.
А вы не предложили ничего конструктивного взамен, и не сможете.
P>>>Именно. Все трояны-вирусы в той или иной степени именно на этом и существуют. Потому и закрывают те или иные возможности, которыми легко злоупотребить.
N>>И вот их обычно закрывают раздельными пользователями и вложенными виртуалками разной степени навороченности — это уже работает — а не мифическими "запретим ставить исполняемость тем, кто сегодня непохож на инсталлятор".
P>Этот мифический запрет почему то отлично реализован в Андроиде.
В Android работает не это, а две других вещи в комплексе —
1) Каждая программа в своей песочнице (как минимум под своим uid), взаимные действия и с общими данными — реализованы через шлюзы.
2) Программы явно получают права на внешние действия и это регулируется пользователем (кроме того, чему система даёт неотменяемые права).
И это тем не менее не устраняет проблемы типа если программе дали доступ к Downloaded files, то она способна стереть оттуда всё, что не понравится. Потому что это уже в пределах одной "гранулы" прав.
Здравствуйте, B0FEE664, Вы писали:
BFE>·>sudo apt-get install git BFE>·>Отсюда: https://git-scm.com/download/linux BFE>И будет установлено какое-то старьё.
А в дебиане нельзя разве дополнительную репу ppa:git-core/ppa добавить?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, netch80, Вы писали:
N>>Но если тебе надо заменить системный git, то единственным правильным способом является собрать пакет из нужной версии и уже средствами пакетного менеджера установить его вместо текущего. BFE>Мда... BFE>Тяжело быть параноиком.
Так тут вопрос даже не столько security, сколько safety.
Иначе апгрейд придёт, заменит тебе git, а ты и не заметишь.
В системах с пакетным менеджером через него крайне желательно делать всё в тех пределах, в которых он действует. Например /usr/bin туда входит, а /usr/local/bin (в большинстве Linux-систем) — нет.
Здравствуйте, B0FEE664, Вы писали:
M>>Если оно что-то и удалит, то только свою песочницу. Там особо терять нечего. BFE>Разве от сценария описанного здесь
Здравствуйте, netch80, Вы писали:
N>В Ubuntu, например, стандартный ~/.bash_profile содержит такие интересные заклинания:
N>
N># set PATH so it includes user's private bin if it exists
N>if [ -d "$HOME/bin" ] ; then
N> PATH="$HOME/bin:$PATH"
N>fi
N># set PATH so it includes user's private bin if it exists
N>if [ -d "$HOME/.local/bin" ] ; then
N> PATH="$HOME/.local/bin:$PATH"
N>fi
N>
Спасибо. Да, это я лажанулся, сейчас посмотрел — в debian по дефолту то же самое. Просто у меня в актуальном этого нет, видимо, когда рабочую версию делал — выкинул, давненько это было.
C>>Создать подкаталог и там распаковать — что-то мешает?
N>Pauel считает, что юзер рано или поздно пойдёт распаковывать напрямую в хомяке.
Да это я понял. Рано или поздно юзер много чего может сделать — свободный человек. Комп, например, в окно выкинуть. Видимо, чтобы это ему не удалось, на окна требуется решётки поставить. И стекло пуленепробиваемое. А лучше — и то, и другое. А юзера — зафиксировать. Наручниками к кровати. Ну, чтобы как бы чего не вышло. А еще лучше — юзера вообще устранить. Нафиг он нужен, мешок кожаный?
C>>Если Вася прислал мне архив, подпись которого корректна, но при этом содержит что-то нехорошее, то Вася очень рискует "получить в бубен". Варианты "бубна" достаточно разнообразны: от собственно "в бубен" до привлечения к решению проблемы правоохранительных органов.
N>Ну вообще-то есть варианты, типа, это был не Вася...
Васю можно и спросить: "Вася, скотина ты эдакая, ты мне архив присылал?" Или договориться с Васей изначально, что если он что-то присылает, то он об этом извещает. Тут, конечно, можно ситуацию и дальше развить — Васю подменили по всем фронтам. Но тут уже начинает работать правило, что (банальные вещи от КО): 1. если захотят взломать — взломают, абсолютной защиты не существует; 2. приемлемая защита заключается в том, чтобы стоимость взлома превышала полученную выгоду.
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, netch80, Вы писали:
N>>2) Программы явно получают права на внешние действия и это регулируется пользователем
P>Ну то есть вы понимаете, что ничего мифического здесь нет.
И при этом я понимаю, что это совсем другой подход с другими особенностями и последствиями, и переносить его результаты на тему обсуждения, как вы пытаетесь делать, просто некорректно.
Здравствуйте, B0FEE664, Вы писали:
M>>Если оно что-то и удалит, то только свою песочницу. Там особо терять нечего. BFE>Разве от сценария описанного здесь
это не спасает? А если спасает, то зачем subj?
Спасает, но только когда мы в песочнице. И ключевой момент здесь в "когда". При сборке проекта (или запуске загруженных бинарников) я прекрасно знаю, что выполняю непроверенный код из потенциально случайных источников. Но при этом далеко не всегда при работе я намерен выполнять внешний код. Может быть, я скачал логи приложения, полученные от клиента, и будут их анализировать. Или какой-то проект, где я хочу просто пролистать исходники. Или, например, документацию к SDK, из которой можно взять какие-то фрагменты кода. С точки зрения максимальной безопасности стоит распаковывать эти проекты в песочнице. Ну хотя бы на случай, если в архиваторе есть ошибки работы с памятью, которые могут приводить к выполнению произвольного кода. Но я еще не дорос до такого уровня паранойи. Мне лень песочницы заводить под сценарии, где я только читаю внешние ресурсы. И вот в этом случае как раз очень удобно знать, что можно спокойно распаковывать архивы и работать с полученным результатом. У меня получается очень небольшой круг опасных операций (запуск кода из внешних источников). Если же разрешать выполнение файлов из текущего каталога, круг опасных операций становится гораздо шире. В него автоматически попадают все внешние (не встроенные в командную оболочку) программы. Это делает повседневную жизнь очень неудобной.
Здравствуйте, BSOD, Вы писали:
BSO>Я правильно понял, что поведение cmd.exe не изменилось, ты имел в виду только PowerShell???
Написал же — попутал, т.к. на заголовок не глянул а экран был черным (привык что PowerShell по умолчанию синий). Открыл по клику правой кнопки, выбор в меню терминал. Думал что это CMD. А потом тему уже было поздно удалять — уже начался холивар.
Pzz>А ты, такой, говоришь ls стоя в этой внутренней директории, вынутой из архива. Ну, чтобы список файлов посмотреть. А потом уже всякое такое говоришь, уже не компьютеру, а ртом, чего я даже воображать не буду, чего говоришь.
Разве AppArmor не защитит от такой ситуации (странно, что его в этой теме не упоминали)?
Насколько я понимаю, там правила, основанные на полных путях, т.е. ls из домашней директории он не даст запустить, пока ты для него новое правило не создашь.
Здравствуйте, m2user, Вы писали:
Pzz>>А ты, такой, говоришь ls стоя в этой внутренней директории, вынутой из архива. Ну, чтобы список файлов посмотреть. А потом уже всякое такое говоришь, уже не компьютеру, а ртом, чего я даже воображать не буду, чего говоришь.
M>Разве AppArmor не защитит от такой ситуации (странно, что его в этой теме не упоминали)? M>Насколько я понимаю, там правила, основанные на полных путях, т.е. ls из домашней директории он не даст запустить, пока ты для него новое правило не создашь.
M>Пишут, что AppArmor в Debian из коробки:
А в контейнерах? А если не Debian?
И вообще эта защита в Unix создавалась лет за 30 до AppArmor и минимум за 15 до самых ранних его аналогов.
M>>Разве AppArmor не защитит от такой ситуации (странно, что его в этой теме не упоминали)? M>>Насколько я понимаю, там правила, основанные на полных путях, т.е. ls из домашней директории он не даст запустить, пока ты для него новое правило не создашь.
M>>Пишут, что AppArmor в Debian из коробки:
N>А в контейнерах? А если не Debian?
На Ubuntu тоже AppArmor.
На RHEL и деривативах вроде SELinux аналогичную защиту должен обеспечивать.
Т.е. средства на базе LSM (Linux Security Modules) вполне используются, а не какая-то экзотика.
N>И вообще эта защита в Unix создавалась лет за 30 до AppArmor и минимум за 15 до самых ранних его аналогов.
Это понятно, но я больше про современный подход к ситуации, описанной в комментарии на который я отвечал.
В треде упоминались такие способы как цифровая подпись исполняемых файлов и всевозможные способы создания изолированного окружения.
Тогда как AppArrmor выглядит гораздо более простым решением.
