Здравствуйте, 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 и т.п. ничему не научил.

Подозреваю, что вы про ActivX только слышали.

Здравствуйте, 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>Вы изобрели один из давно известных способов внедрения у троянов. С архивами абсолютной гарантии никто не даст — всегда можно найти уязвимость, основываясь на привычках пользователей.
Не изобрёл, просто напомнил, что предлагаемые тобой способы сливания в унитаз ноутбука — ерунда на постном масле.

Здравствуйте, B0FEE664, Вы писали:

BFE>Серьёзно? В 21-ом веке SSH-only? Без SFTP? у нормальных людей? Не верю!
BFE>А раз есть SFTP, то (с помощью плагина) Total Commander будет работать без проблем.
Ну-ну. Запусти в TC тот-же top, например.
ssh — базово и массово применяется для управления серверами. Плагинами к TC пользуются только фанатики TC, да и то, как показывает практика, только первое время. Потом сначала в putty перепозают и следом в wsl2+windows terminal

Здравствуйте, 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-ом веке терминал для файловых операций, это всё равно, что смотреть на графический экран через замочную скважину. Оно, конечно, можно, но страшно неэффективно не неудобно.

Здравствуйте, 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 тот или иной фолдер.
Это и есть тот случай — защита фигня, потому что её можно отключить по инструкции.

·>Другими словами, почему ты считаешь, что разрешать фолдеры компилятору — сознательный акт, а распаковка архивов в явно указанный фолдер — непреднамеренный?

Вас похоже телепатия за яйца крепко держит.
Если юзер хочет заниматься компиляцией, он обязан разрешить тот или иной фолдер. Какой разрешит — такой и эффект будет. Разрешит / или ~/ — сам себе буратино.
Распаковка архивов — ровно то же. И там, и там по дефолту / и ~/ должны быть закрыты. Тогда непреднамеренные действия будут ограничены.

·>Мы вроде сабж обсуждаем. Именно он и делает хоть какую-то защиту. Возможность создать (неважно каким способом) файл в любой случайной директории и случайно его выполнить потому что его имя совпало с какой-нибудь системной командой — это огромная дыра в безопасности.

А кто спорит, что это дыра? Я пишу том, что есть и другая дыра — архиваторы, т.к. их используют как замену пакетным менеджерам. Например у вас есть такое же видение, что архиватор и инсталятор это одно и то же.

Здравствуйте, B0FEE664, Вы писали:

BFE>Как вы, параноики, от этого защищаетесь?

Полно вариантов: fakeroot, mock, docker, отдельный пользователь, отдельная виртуалка.

BFE>Особенно если учесть, что следующая естественная команда, это sudo make install...

Естественная?

Здравствуйте, Pauel, Вы писали:

P>>>Вам бы пореже телепатией пользоваться.
P>·>Чем изменение path случайнее, непреднамереннее распаковки архива с указанием bin?
P>Расскажите, как вы случайно, не глядя, чего то добавите в path. Подробнее.
В линухах — никак. О том и речь. В винде — до сабжа — запросто. И трояны есть именно в винде, несмотря на сервисы, api иснталляторов, веб-метки и прочий бред.

P>Вы привели пример противоположного действия — сознательно вписать в path тот или иной фолдер.
Это что уже десятилетия существует в линухах без всяких предложенных тобою как новшество "разрешенных фолдеров".

P>·>Другими словами, почему ты считаешь, что разрешать фолдеры компилятору — сознательный акт, а распаковка архивов в явно указанный фолдер — непреднамеренный?
P> Вас похоже телепатия за яйца крепко держит.
P>Если юзер хочет заниматься компиляцией, он обязан разрешить тот или иной фолдер. Какой разрешит — такой и эффект будет. Разрешит / или ~/ — сам себе буратино.
P>Распаковка архивов — ровно то же. И там, и там по дефолту / и ~/ должны быть закрыты. Тогда непреднамеренные действия будут ограничены.
/ и так уж в линухах закрыт, с рождения. ~ закрывать — бред и никакой безопасности не добавит, т.к. ~ в path ставят куда надо, а не куда попало.

P>·>Мы вроде сабж обсуждаем. Именно он и делает хоть какую-то защиту. Возможность создать (неважно каким способом) файл в любой случайной директории и случайно его выполнить потому что его имя совпало с какой-нибудь системной командой — это огромная дыра в безопасности.
P>А кто спорит, что это дыра? Я пишу том, что есть и другая дыра — архиваторы, т.к. их используют как замену пакетным менеджерам. Например у вас есть такое же видение, что архиватор и инсталятор это одно и то же.
Верно, одно и то же с т.з. безопасности. Потому что совершенно неважно какая именно прога создаёт файлы.