Здравствуйте, 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, из которой можно взять какие-то фрагменты кода. С точки зрения максимальной безопасности стоит распаковывать эти проекты в песочнице. Ну хотя бы на случай, если в архиваторе есть ошибки работы с памятью, которые могут приводить к выполнению произвольного кода. Но я еще не дорос до такого уровня паранойи. Мне лень песочницы заводить под сценарии, где я только читаю внешние ресурсы. И вот в этом случае как раз очень удобно знать, что можно спокойно распаковывать архивы и работать с полученным результатом. У меня получается очень небольшой круг опасных операций (запуск кода из внешних источников). Если же разрешать выполнение файлов из текущего каталога, круг опасных операций становится гораздо шире. В него автоматически попадают все внешние (не встроенные в командную оболочку) программы. Это делает повседневную жизнь очень неудобной.
Здравствуйте, 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???
Здравствуйте, 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 выглядит гораздо более простым решением.
