На самом деле первый подход безопаснее и лучше, так как позволяет избежать всех угроз, а не только одной единственной.

@anonim Угроза на свободе а человек - нет. Во втором случае угроза в клетке [видимо в виртуальной машине].

@engineer Любое стремление к безопасности означает жертвование некоторым количеством удобств. Подход со второй картинки хорош для разработки компьютерных систем, но в отношении действий человека лучше применять первый, потому что редко когда возникает возможность изолировать саму опасность. // как-то я упорото объяснил, но надеюсь более-менее понятно.

@engineer невозможность залезть в чужое адресное пространство и писать в физические адреса - это какой вариант, первый или второй?

@muromec Второй.

@muromec Я думаю первый вариант можно отождествить с MMU, иерархическими зонами защиты (кольцами) а второй - с виртуальной машиной реализующей capability based security.

@anonim При соблюдении нескольких условий, в особенности если у процессов нет возможности совершать арифметику над указателями (получать новые указатели из старых), получается так что процессы не могут никаким образом получать доступ к объектам которые не были им переданы (их может раздавать ОС). Это убирает очень большой класс уязвимостей которые существуют в наших системах сейчас.

@engineer это схуяб MMU и кольца защиты - первый вариант, кто вообще в случае с MMU будет в клетке, а кто вне?

@muromec MMU и кольца - грубая, дырявая клетка. Они предоставляют процессам возможность доступа к гораздо большему количеству ресурсов чем им нужно для нормальной работы. Стоит получить через какие-нибудь игры с указателями и переполнением буфера доступ к привелигированной части [памяти] системы и вся система находится в руках злоумышленника. Эти костыли очень сложны (x86 MMU полон по Тьюрингу https://github.com/jbangert/trapcc) и содержат в себе большое количество нераскрытых уязвимостей, потому всегда есть опасность что кто-то их найдёт. Отсюда и боязнь собаки. В альтернативной модели права доступа контролируются гораздо более точно, потому таких проблем и страхов нет и даже можно будет доказать надёжность системы.

@engineer я долбоеб, не посмотрел на картинки. конечно MMU - это первый. вопрос в том, кто находится *снаружи* и от кого защищаемся?

@muromec Снаружи хакеры-сопляки со своими шелл-кодами и всякой дрянью.

@engineer mmu защищает от шелл-кодов?

@engineer >Эти костыли очень сложны это неправда. >x86 MMU полон по Тьюрингу восемь-шестая машина - не единственная машина с MMU. >В альтернативной модели права доступа контролируются гораздо более точно обосновать?

@muromec Может помочь в защите, но в современных системах слишком много дыр чтобы это что-то решало. Шелл-код этоже обычно просто полезная нагрузка какого-то эксплойта. Вобще я обладаю довольно поверхностными (малое, но ненулевое количество практики) знаниями в области взлома систем.

@engineer бро, ты натягиваешь аналогию не на тот хуй. mmu, если не рассматривать фокусы с NX-битом, вообще никаким боком к всякому шелл-коду. поэтому на вопрос "кто снаружи" ты не ответил.

@muromec >обосновать? Два раза уже обосновывал. Capability based security позволяет регулировать доступ к отдельным объектам в памяти, можно давать каждому процессу использовать только то что ему нужно. >восемь-шестая машина - не единственная машина с MMU. Я знаю это. И что с того? >это неправда. 4-5 колец защиты это мало, вместе с Тьюринг-полным MMU? В ARMах тоже уже есть TrustZone.

@muromec NX бит важен же. Если шелл-код внедряется через переполнение какого-нибудь буфера в зону памяти с запрещённым выполненеим (NX = 1) то его не получится выполнить. Я и не спорю что тут аналогия неполная с картинкой. Те кто её составлял наверняка думали совсем о другм чем я.

@engineer >4-5 колец защиты это мало, вместе с Тьюринг-полным MMU? ты рассматриваешь концепцию MMU или ее реализацию в восемь-шестой машине? в армах и мипсах MMU не сложный. вообще говорить слово "сложный" про мипсы - это самому себя послать нахуй >доступ к отдельным объектам в памяти виртуальная машина проще MMU? да ты шутник, я смотрю!

@engineer я конечно спасибо, что обеснил про NX-бит, но именно поэтому и написано выше "если не учитывать".

@engineer > права доступа контролируются гораздо более точно почему это трактуется, как "снаружи клетки", если контроля *больше*?

@engineer фактически ты сейчас доказываешь, что одна клетка хуевая и внутрь можно просунуть хуй, а другая клетка в мелкую яцейку и просунуть ничо нельзя.

@muromec Да, говорим о x86 как о доминирующей пока серверной архитектуре. Да и дело не в железе а в подходе к написанию ОСей и программ который делает безопасность сложным вопросом, благодаря чему многомиллиардная индустрия "защиты информации" и взлома живёт. >виртуальная машина проще MMU Виртуальная машина занимает 0 мм^2 места на кристалле, в отличие от логики MMU и TLB. Виртуальную машину можно обновить и улучшить если в ней найдены недостатки, кремний придётся производить заново. Разработка программ проще разработки железа.

@muromec Я это вижу вот как: с обычным железом и ОС у взломщика есть очень большой простор для творчества (куча плохо документированных особенностей программ и железа и способы для их использования). Пользователю же приходится ограничивать себя во всём (не загружать .exe-файлы из сети и т.д. потому что они могу запросто всю систему порушить). Это первая картинка. Виртуальная машина где программам (через дыры в которых пользователь пытается нанести вред системе) впринципе даётся минимум ресурсов это и есть клетка, и злоумышленник сидит в ней а пользователь снаружи - можно загружать исполняемые файлы из сети точно заня что если им запрещается всё кроме вывода изображения в окно то они ничего больше сделать не смогут. Вот. теперь понятно?

@engineer >Да, говорим о x86 как о доминирующей пока серверной архитектуре. а схуяб ты экстраполируешь недостатки этой машины на MMU вообще? >Виртуальная машина занимает 0 мм^2 места на кристалле пошутил ага. MMU занимает 0 мегабайт в памяти. >Разработка программ проще разработки железа. нет.

@engineer >точно заня что если им запрещается всё кроме вывода изображения в окно то они ничего больше сделать не смогут. если ты хотел описать ведроды, то открою грязную тайну - там обычный линукс на обычном арме и все вышеперечисленное реализуется именно за счет MMU.

@muromec MMU это пример когда программную проблему пытаются решить аппаратными средствами и получается плохо. Кольца защиты туда же. >MMU занимает 0 мегабайт в памяти. Даа? Код для его поддержки тоже немаленький. А ещё есть здоровенная структура в памяти которая хранит все эти атрибуты страниц. >нет. Ты наверное не слышал о том как это быть без права на ошибку при разработке какой-нибудь SOC. Программирование энтерпрайза на этом фоне примитив с низеими требованиями к надёжности.

@muromec Я описываю Smalltalk-80, Genera Os, Phantom OS. Список можноп родолжать но там уже будут компромиссные проекты.

@engineer >Даа? Код для его поддержки тоже немаленький. А ещё есть здоровенная структура в памяти которая хранит все эти атрибуты страниц. на порядок меньше, чем реализация VM, у которой еще большая структура, хранящая права доступа к объектам.

@engineer среди систем с MMU ты взял самую распространенную, а среди капабилити-бейзед - какое-то мертвое говно. ну ок.

@muromec Значит ты не понимаешь идеи. Структура как раз не нужна. Просто тем кому "нельзя" ОС не даёт ссылку на объект. Это гарантирует то что доступа не будет. Информация о том кому можно и кому нельзя очень хорошо сжимается и хранится в каком-то дереве в ОС.

@engineer >Просто тем кому "нельзя" ОС не даёт ссылку на объект. а чтобы отличить объект одного типа от другого, нужно эту инфу где-то хранить.

@muromec Предложи свой вариант. То что я предложил - системы на которых работает довольно большое кол-во приложений (Phantom OS слишком молод ещё).

@engineer я тебе написал про ведроеды. если ты не понимаешь, что ведроеды реализуют ту же самую концепцию мессаж пассинга, что и смоллтолк, то извинити.

@muromec Проверка типов во времени выполнения это другой вопрос, связанный с нашим лишь косвенно. Хорошие виртуальные машины содержат оптимизирующие компиляторы убирающие лишние проверки. А теги в указателях это полезно но необязательно. Для реализации capability based security достаточно просто отсутствия адресной арифметики на уровне VM.

@muromec Эээ, ты о чём вобще? Всё в кучу. Ты же уже сказал что андройд не годится потому что там линукс и в этом я с тобой согласен. К тому же там отказались от работы приложений тольео через VM и позволяют запускать Native приложения. Message passing в java нет на уровне языка. В андройде на уровне системы это одна изв озможностей.

@engineer >К тому же там отказались от работы приложений тольео через VM и позволяют запускать Native приложения. и хуле? >В андройде на уровне системы это одна изв озможностей. без мессаж пассинга в андроиде нельзя написать *нихуя*.

@engineer >адресной арифметики на уровне VM. на уровне языка или на уровне vm?

@muromec На уровне VM, в которой работает весь код, возможно и с системными драйверами.

@muromec Мне кажется наше недопонимание седует из того что ты показываешь мне что и со современными Ос можно как-то работать а я думаю о том как должна выглядеть ОС где обсуждаемых проблем нет как класса.

@muromec То что мы имеем сейчас это регресс по сравнению с Генерой и смоллтолком.

@engineer окей, как на уровне VM выглядит доступ к объекту? по имени, по адресу, по "идентификатору"?

@muromec По ссылкам. В VM Smalltalk доступ к методу определяется через опкоды вроде SEND.

@muromec Реализация ссылок - проблема людей реализующих VM.

@engineer что такое "ссылка"? что пишется в инструкции после опкода SEND?

@engineer нихера не понял. у меня в одной VM будет SEND циферка, а в другой - SEND "имя объекта хуй пизда через точечки"?

@muromec SEND берёт ссылку на receiver и arguments из стека.

@muromec Smalltalk VM примечательна тем что в ней даже арифметика на сообщениях реализована, там полная проверка типов в рантайме (но умные VM отключают её в циклах если могут). http://smalltalk.gnu.org/files/vmspec.pdf

@engineer а как это выглядит на стеке?

@muromec Если есть пара объектов (ссылок на них, но число может быть встроено в ссылку с помощью тега) на стеке то они выкидываются из него, выполняется команда SEND (там много чего может произойти, объекты могут понимать сообщения по-разному или не понимать) результат кладётся в стек. Формат представления объектов, встраивания чисел в ссылки зависит от VM.

@engineer ну и кто мне мешает записать в стек любой интежер, а потом ебнуть SEND?

@muromec Integer это тоже объект, он не может превратиться в ссылку на что-то другое. Приведения ссылок к числам и обратно в этой VM нет. Ты не можешь сделать ссылку из ничего если работаешь внутри VM (вариант "записать в память ручками с помощью отладчика" это не то что я отрицаю).

@engineer а, стек тоже типизированный. а берется ссылка откудова?

@muromec Эээ. Ты путаешь реализацию и спецификацию. Да, в конце концов стек это область в памяти содержащая машинные слова-указатели. Но в байткод исполняемый VM не может, ну нету таких опкодов, чтобы изменить эти указатели как ему хочется. Он может создавать новые объекты, получат существующие по ссылкам, вызывать их методы и всё.

@engineer ладно, я поверил, что эта хуета анбрейкбл, но говорить, что это проще или там "свободнее" - это гонево. в том же андроиде юзается капабилити бейзд, но при этом можно гонять нативный код и это безопасно. тут нельзя. в клетке сидит девелопер. поэтому оно и сдохло.

@muromec Да не верь, дело твоё. Читай статьи же. Вобще smalltalk-80 это слишком сильно отличается от нынешнего чтобы сразу понять, может с JVM тебе бы было проще, там те же самые ограничение на арифметику указателей. Свободнее это когда не надо антивируса ставить и разблокировать компьютер за СМС. Андройд настолько безопасен что под него антивирусы клепают.

То есть, правильно — каждого потенциального взломщика или вирусописателя ловить и сажать в клетку?

@goren Хорошая шутка. Я думаю мы с муромцем многое тут уже разобрали чтобы было понятно.

@engineer Это не шутка, это вопрос с подвохом.

@engineer >Андройд настолько безопасен что под него антивирусы клепают. ты начинаешь гнать хуйню. во-первых, наличие антивирусов и необходимость в них - это разные вещи. во-вторых, необходимость антивирусов и разграничение прав через MMU вместе с запуском нативного кода надо связать. насколько я понимаю, там ситуация как раз в том, что *пользователь* разрешает установку приложений не глядя на капабилити. смоллтолк от этого защищауе?

@engineer >Да не верь, дело твоё. Читай статьи же нахуя мне читать статьи про неюзабельно древнее говно из 80ых? оно сдохло вместе с дикими идеями про арифметику через отправку сообщений и слава вечному ништо.

@goren Я презираю взломщиков-сопляков, к тому же из них 99% программировать не умеет. Однако это не значит что я буду их бить, четвертовать, унижать физически и сажать в клетку. Кстати, интересно твоё мнение по поводу того является ли взлом чужого компьютера агрессивным насилием (повреждением собюственности и т.д.).

@engineer Это вопрос такой гуманитарно-философский. Ты же, помнится, сам говорил, что информационного насилия не бывает? Вопрос же такой — тебе не кажется, что то, чем занимаются (пытаются заниматься) касперский и ко. — это предельный вариант второго подхода (изоляции угрозы)?

@goren ой блядь, в треде явно не хватает картинки, где чувак лежит на шезлонге с пистолетом под подушкой, а тигр сделал ноги от такой хуйню.

@goren 1) Да, информационного насилия я не признаю потому что это не объективно определимое понятие как и информация (если начать считать и.н. объективным то можно как один наш знакомый прийти к тому что рекламу считать насилием). Хотя в NAP есть упоминание относительно "угрозы агрессивного насилия" который тоже меня занимает. Но этот пункт хотябы выглядит определимым в отличие от того что мы обсуждаем. Вопрос классификации компьютерного взлома как насилия или не-насилия меня давно занимает, пока что я не нашёл достойного ответа на него. Задача звучит так: Рассмотрим компьютер (у него есть владелец, в машине хранится информация которую он не хочет разглашать) подключённый к проводной сети. Под взломом я буду подразумевать целенаправленную генерацию сигналов злоумышленником, которые заставляют машину владельца делать то что ему не не нравится, например отправлять инфорамцию владельца в сеть, удалять информацию или даже физически ломаться. Является ли взлом машины в указанном выше смысле агрессивным насилием? Зависит ли это от того что злоумышленник сделал с машиной? (Варианты: скопировал информацию, сломал машину, или же кому-то физически навредил) Далее вопрос упирается в определение насилия по отношению к собственности. Насилие применительно к собственности можно определить как действия (как я понимаю необязательно сводящиеся к физическому контакту с собственностью), физически влияющие на собственность владельца против его воли. (Если тебе не нравится такой критерий, предложи мне свою формулировку, это важно) Сигналы посланные злоумышленником заставили машину владельца производить какие-то физические операции, двигать дисками, обращаться к памяти и т.д. которых не хотел пользователь, значит это соответствует изложенному выше определению. Тут опять же всё зависит от того что значит "физически влиять на собственность владельца против его воли" - является ли лишнее считывание из памяти и отправка данных в сеть "влиянием"? Вопрос становится ещё абстрактнее и тоньше если мы будем рассуждать о беспроводных интерфейсах, например о тех через которые управляются боевые БПЛА - если злоумышленник перенял контроль над БПЛА и разрушил его или с его помощью кого-то убил, будет ли это являться насилием? Я думаю что будет, потому что налицо вред нанесённый частной собственности или другим людям. На ум ещё приходят другие ответы на этот вопрос, которые мне нравятся меньше: 1.А) Можно сказать что подключив машину к сети владелец подразумевает что он согласен с тем как машина будет реагировать на любые сигналы из сети, и если на какой-то сигнал последовала вредная или разрушительная для него реакция то он сам виноват. (Мне это кажется несправедливым особенно в случае если были человеческие жертвы - захват завода с роботами например) 1.Б) Можно при подключении к сети брать договор где человек обязуется не посылать в сеть такие сигналы которые приведут к поломке чужой машины, и в случае нарушения брать штраф согласно с договором. (Хорошо если можно взять договор, ведь в беспроводной связи подключается любой у кого есть передатчик). 2) Касперскому, Макафе и компании выгодно чтобы люди пользовались дырявыми программами для которых можно продавать заплатки а взломщики придумывали всё новые способы взлома. Я рассматриваю и "специалистов по компьютерной безопасности" и взломщиков симбиотическими компонентами паразитирующей на остальных людях группы. Сейчас в Америке да и в других странах распиливаются очень большие деньги под маркой "кибербезопасности". Макафе кстати живёт как наркобарон, т.е. его вкусы напоминают бандитские. В любом случае эти вопросы мне кажутся важными и над ними стоит думать. Возможно у классиков не хватило времени и желание чтобы это продумать, а может они упустили что-то фкндаментальное про информацию.

@engineer Ну поскольку ты не признаёшь материальность информации, приходится признать, что она не может быть собственностью и против неё не может быть никакого насилия. Насилием будет только то, что несёт какие-то последствия против жизни и собственности людей в материальном мире — например, физическое разрушение или вывод из строя какого-нибудь оборудования, нарушение процессов производства, транспортировки или хранения материальных вещей, травмирование или гибель людей. Во всех этих случаях имеет место материальный ущерб, который можно оценить и возмещения которого можно требовать. Что же до "интеллектуальной собственности", то любая информация принадлежит любому, кто смог её получить, и он может делать с ней всё, что заблагорассудится. Если не хочешь, чтобы какая-то информация стала доступна большому числу людей — просто не делись ей ни с кем и защищай получше.

@goren Ты упрощаешь вопрос. Есть разница в копировании информации с носителя который принадлежит тебе и носителя который принадлежит кому-то другому.

тлдр кудах сосу хуй нет ты неправ

@engineer Нет, нет разницы.