S>Здравствуйте, ononim, Вы писали: O>>Ну вот зачем сразу утрировать и пытаться свести к абсурдности? В стандартном DACL вы тоже перечисляете всех и каждого или там еще группы есть? S>Стандартный DACL, как мы знаем, от малвари защищает чуть меньше, чем никак. S>Поэтому я и пытаюсь понять, что именно делается.
Он отлично защищает от малвари от которой задуман защищать, а вы все так же банальным утрированием пытаетесь все свести к абсурду. Беда стандартного дакла что он первично защищает системные объекты, а не информацию. Грамотно воспользовавшись даклами вполне можно и информацию защитить, но очень сложно сделать это через дебри косвенности между объектами ОС и информацией на которую может повлиять их модификация. Я же по сути предлагаю накладывать аналог DACLа (а точнее — SECURITY_DESCRIPTOR'а) на саму информацию. Причем помимо DACL'а в операционках есть process, token или еще какой нить объект описывающий того 'против' кого работает SD. В моей абстрактной модели нет такого разграничения — я предлагаю классифицировать доступ информации к информации.
S>>>А у кого будут права на запись в базу идентификаторов? O>>У ядра оси, разумеется. Тут — полная аналогия с системой виртуальной памяти. O>>Заранее сразу отвечаю на пару вопросов: O>>1) Ядро оси никто не сможет модифицировать, окромя тех кому можно (а можно — информации, созданной производителем оси). O>>2) ДА. Это получится очень анально огороженная архитектура.
O>>3) _Можно_ развить концепцию до еще более анально огороженной trusted hardware platform: O>>3.а) Писать в базу идентификаторов сможет только железо (зашитая в нем фирмварь) O>>3.б) Сетевые адаптеры должны аппаратно поддерживать SSL. Любая входящая по сети информация должна автоматически тегироваться группами, прописанными в сертификате другой стороны. Если не SSL — значит группа anonymous. O>>3.в) У пользователя системы должен быть личный сертификат, с помощью которого клава/мышь/тач так же будут тегировать весь его ввод, с возможностью криптографической его верификации в случае необходимости (банковская транзакция, заказ авиабилета, пост в КЫВТ...) S>Это всё малоинтересные подробности. S>Давайте поймём простую вещь: вот у меня есть, допустим, авиабилет, купленный на сайте аэрофлота. У меня, допустим, есть приложение А — "календарь", с разрешением синхронизоваться с моим смартфоном. Для упрощения предположим, что это — веб приложение, т.е. просто другой сайт. Есть сценарий "добавить данные авиабилета в календарь". Естественно, мы предполагаем, что само приложение календаря было разработано независимым вендором через пять лет после того, как сайт аэрофлота был запущен. S>Что должен сделать и кто чтобы разрешить пользователю выполнить этот сценарий?
Создатель приложения должен будет квалифицировать возможность применения информации, сгенеренной его приложением. Опять же опустимся к DACL'ам. В юниксах любят троицу owner/group/world. У нас в принципе выделяется троица домен создателя информации, домен пользователя которому она придет, и — все остальные. Соответственно в первом приближении если создатель приложения разрешил 'миру' читать его информацию — ты сможешь ее передать куда угодно. Если нет — никуда не передашь. Во втором приближении появляются группы, и создатель может выдать разрешение определенным группам, в которые возможно и попадет сайт аэрофлота в будущем, если он того пожелает и если это заапрувит certificate authrity. А может и нет — ну, никтож не обещал утопию.
Как много веселых ребят, и все делают велосипед...
Re[12]: Безопасность ОС. Можно ли решить кардинально?
Здравствуйте, ononim, Вы писали:
O>Он отлично защищает от малвари от которой задуман защищать,
Пока что этого не видно. O>а вы все так же банальным утрированием пытаетесь все свести к абсурду.
Я пытаюсь проверить граничные случаи. А вы похоже вообще ни один из реальных сценариев не продумали от начала и до конца.
O>Создатель приложения должен будет квалифицировать возможность применения информации, сгенеренной его приложением. Опять же опустимся к DACL'ам. В юниксах любят троицу owner/group/world. У нас в принципе выделяется троица домен создателя информации, домен пользователя которому она придет, и — все остальные.
А что, у всех пользователей есть свои домены? У меня, к примеру, нету.
O>Соответственно в первом приближении если создатель приложения разрешил 'миру' читать его информацию — ты сможешь ее передать куда угодно. Если нет — никуда не передашь.
В этом приближении задача неразрешима. Потому что "куда угодно" — это, в частности, злоумышленнику, который сдаёт билет и получает деньги. (В более реалистичном случае, возможном прямо сейчас, он сдаёт билет не для денег, а чтобы освободить место на нужный ему рейс).
А "никуда не передашь" означает принципиальную невозможность добавить вылет в расписание.
O>Во втором приближении появляются группы, и создатель может выдать разрешение определенным группам, в которые возможно и попадет сайт аэрофлота в будущем, если он того пожелает и если это заапрувит certificate authrity. А может и нет — ну, никтож не обещал утопию.
Это не утопия, это минимально необходимый уровень сервиса. Получается, что у вас всё построено на группах.
Значит, надо их архитектуру проработать как-то более тщательно. Ну и оценить всё же накладные расходы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Безопасность ОС. Можно ли решить кардинально?
Здравствуйте, ononim, Вы писали:
O>Нужно эффективное тегирование памяти. Чтоб точно трекать происхождение каждого байта, имеющегося в системе. Ведь любая имеющаяся на компе информация — она либо введена юзером, либо взята извне. Соответственно если пометить лейблой каждый байт, можно будет отследить его родословную и принять решение при выходе этой информации за пределы компа — выпускать ее или нет.
Просто интересно: а отрендеренный на экране суперсекретный текст будет приводить к невозможности создать и куда-нибудь отправить скриншот? Считать инфу попискельно из параллельного процесса? А если морзой пропищать защищенный таким образом регион памяти, другой процесс сможет его прослушать через микрофон и отправить злохакерам?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Порча памяти здесь не причем. .NET-приложение, подверженное атакам, связанным с порчей памяти еще поискать надо. Но это не делает .NET приложения неуязвимыми, т.к. атаки на подобные уязвимости составляют около трети от числа всех ныне известных WH>А можно список других уязвимостей?
Не знаю ни одного, эффективно реализуемого без необходимости необоснованно доверять третьей стороне
KV>>Как быть с приложениями, поддерживающими плагины WH>1)Плагин при всём желании не сможет сделать больше, чем позволено приложению.
В современных реалиях большего и не нужно. Хотя за рамки угроз уровня ОС это конечно выходит.
O>>Нужно эффективное тегирование памяти. Чтоб точно трекать происхождение каждого байта, имеющегося в системе. Ведь любая имеющаяся на компе информация — она либо введена юзером, либо взята извне. Соответственно если пометить лейблой каждый байт, можно будет отследить его родословную и принять решение при выходе этой информации за пределы компа — выпускать ее или нет. KV>Просто интересно: аа отрендеренный на экране суперсекретный текст будет приводить к невозможности создать и куда-нибудь отправить скриншот? Считать инфу попискельно из параллельного процесса?
Пиксели — это не более чем ячейки (видео) памяти, которые разумеется тоже должны быть меченые.
KV>А если морзой пропищать защищенный таким образом регион памяти, другой процесс сможет его прослушать через микрофон и отправить злохакерам?
Интересный вопрос. Както я про такой сценарий не задумывался, но вообще ответ в голову пришел: если на динамики отправляется какая либо информация и при этом с микрофона идет запись — вполне логично считать входящую информацию с микрофона облагаемой теми же пермишенами, как и проигрываемая в тот же момент. Кроме того информацию можно явне тегировать как не подлежащую отправку в аудиоустройства (а точнее — явно тегировать только то, что можно проигрывать) и такая проблема вообще не возникнет.
И еще сразу отвечу на висящий в воздухе вопрос, по поводу секретных данных, которые могут быть перепечатаны/прочитаны/насвистаны/записаны на магнитофон самим юзером. Против _юзеров_, которые специально тырят секретные данные которые сами могут просматривать на горизонте решений не просматривается (вживление микрочипов в мозг — это пока еще за горизонтом ). Натайпанные юзером данные автоматом будут считать произведенными юзером и иметь соответствующие разрешения. Но вот касательно этих разрешений есть ньюанс:
1) Если юзер задасться целью слить свои данные злоумышленникам — он это всегда сможет сделать. В плане защиты от утечек информации эта штука будет работать только при сотрудничестве со стороны юзера. От промышленного шпионажа это решение — лишь очередной слой obscurity.
2) Если же юзер сам заинтересован чтобы сохранить эти данные в секрете, но при этом мы боимся что его обманным путем (вплоть до гипноза) их заставят натайпать, то несложно будет сделать классификацию вводимой информации, наподобии тех что ставятся в корпоративных периметрах и сканят например почту на предмет случайного сообщения потенциально секретных данных потенциальному злодею. Основная проблема таких существующих решений — что секретная информация на периметре может быть в совершенно любом виде, поэтому даже самый допропорядочный юзер может случайно слить ее, например переслав каким нить малоизвестным месенжером, не говоря уж о малварном софте, который может просто все зашифровать способом известным лишь его автору и отправить под видом DNS запросов. А вот информация поступающая с HID'ов — она всегда в известном формате, и анализировать для автоматической классификации ее там будет намного проще — вплоть до околонулевого участия юзера в этом деле. Ну а после классификации ее уже никак не стырить будет.
Как много веселых ребят, и все делают велосипед...
Re[13]: Безопасность ОС. Можно ли решить кардинально?
O>>Он отлично защищает от малвари от которой задуман защищать, S>Пока что этого не видно. O>>а вы все так же банальным утрированием пытаетесь все свести к абсурду. S>Я пытаюсь проверить граничные случаи.
До сих пор вы задавали вопросы с очевидными ответами, тем не менее делая вид что не видите этих ответов. Ну или правда совершенно не задумывались и потому их не видели.
S>А вы похоже вообще ни один из реальных сценариев не продумали от начала и до конца.
Вообще эта идея мне пришла в ходе ресерча на тему как улучшить один наш rights managment продукт. Когда я рассказал менеджменту идею и показал тормозящий Блокнот, сказав что если вложить дофига усилий можно получить офигенную конфетку, но к сожалению не могу пока предсказать из какой она будет субстанции — менеджмент почесал бошку и сказал ну его нафиг, давайте лучше дальше наши кривохаки пилить. А о том что такая модель безопасности вобщемто тянет на замену устоявшимся юникс пермишенам и даклам я вообще тогда промолчал, дабы совсем у виска не покрутили. А сейчас вот прочитав эту ветку — вспомнилось. Так что не надо ожидать что я прямо вот ща вам вывалю whitepaper на тыщу страниц и печатью ОТК за подписью Брюса Шнайера и ведущих специалистов по юзабилити.
Просто текущие системы безопасности NT/Unix тащат свои корни с лохматых времен с мэйнфреймами, на которых сидели различные пользователи, и каждый пользователь делал какую нибудь одну, но очень важную для него вещь. В таком окружении та модель замечательно работает: там пользователь == защищаемые данные. Проблема в том что сейчас ее пытаются натянуть на однопользовательское окружение, в котором куча разных данных, совершенно различными "степенями секретности", но все они варятся в едином котле одного уровня привилегий. А разделить уровни — непонятно как, потому что просто нет прямого и естественного пути их перегруппировать, причем так чтоб потом еще и можно было шарить друг с другом. Опять же старая модель безопасности предполагала наличие админа, который бы всем настроил пермишены и сказал кому что можно, а кому что нельзя. В нынешней же солянке информации на типичной системе никакой админ не разберется, кроме того она постоянно меняется. Для защиты данных нужна новая модель безопасности, которая защищает именно данные, а не какието произвольные сущности которые с конкретными данными однозначно и на словах увязать то сложно, а не то что формально описать и запрограммировать.
Как много веселых ребят, и все делают велосипед...
Re[14]: Безопасность ОС. Можно ли решить кардинально?
... O>Просто текущие системы безопасности NT/Unix тащат свои корни с лохматых времен с мэйнфреймами, на которых сидели различные пользователи, и каждый пользователь делал какую нибудь одну, но очень важную для него вещь. В таком окружении та модель замечательно работает: там пользователь == защищаемые данные. Проблема в том что сейчас ее пытаются натянуть на однопользовательское окружение, в котором куча разных данных, совершенно различными "степенями секретности", но все они варятся в едином котле одного уровня привилегий. А разделить уровни — непонятно как, потому что просто нет прямого и естественного пути их перегруппировать, причем так чтоб потом еще и можно было шарить друг с другом. Опять же старая модель безопасности предполагала наличие админа, который бы всем настроил пермишены и сказал кому что можно, а кому что нельзя. В нынешней же солянке информации на типичной системе никакой админ не разберется, кроме того она постоянно меняется. Для защиты данных нужна новая модель безопасности, которая защищает именно данные, а не какието произвольные сущности которые с конкретными данными однозначно и на словах увязать то сложно, а не то что формально описать и запрограммировать.
В нынешнем окружении полным полно сложных случаев, когда и старая система ставила палки в колеса. Например 24 сентября стим (Steam) впервые пофиксил:
Fixed failing to draw Web views into games that run as the elevated user when Steam wasn't also elevated
. И таких сценариев когда сервисы и программы водят хороводы и гоняют данные из сети туда-сюда не так мало. Надеюсь если этот "мега-дрм" начнет материализовываться юзерам не придется рвать волосы разработчиков =)
Re[8]: Безопасность ОС. Можно ли решить кардинально?
Здравствуйте, ononim, Вы писали:
KV>>А если морзой пропищать защищенный таким образом регион памяти, другой процесс сможет его прослушать через микрофон и отправить злохакерам? O>Интересный вопрос. Както я про такой сценарий не задумывался, но вообще ответ в голову пришел: если на динамики отправляется какая либо информация и при этом с микрофона идет запись — вполне логично считать входящую информацию с микрофона облагаемой теми же пермишенами, как и проигрываемая в тот же момент. Кроме того информацию можно явне тегировать как не подлежащую отправку в аудиоустройства (а точнее — явно тегировать только то, что можно проигрывать) и такая проблема вообще не возникнет.
Не, такие вещи отследить вряд ли возможно. У Эндрю Таненбаума в книге "Операционные системы. Разработка и реализация" где-то был пример скрытной передачи информации путем отслеживания нагрузки процессора — если активность в течение какого-то времени выше определенного порога, то это 1, если ниже — то 0.
В общем, эти штуки идут в ту же компанию, что и социальная инженерия — для борьбы с угрозами такого типа нужны принципиально иные подходы.
Re[14]: Безопасность ОС. Можно ли решить кардинально?
Здравствуйте, ononim, Вы писали: O>До сих пор вы задавали вопросы с очевидными ответами, тем не менее делая вид что не видите этих ответов.
Пока что вы ни на один из них толком не ответили. Как я и полагал, у вас хорошо продуман нижний уровень, но нет ни малейшего представления о том, как из этого нижнего уровня собрать решение для пользовательских сценариев. Я сам таким изобретательством занимался в 19 лет
O>Вообще эта идея мне пришла в ходе ресерча на тему как улучшить один наш rights managment продукт. Когда я рассказал менеджменту идею и показал тормозящий Блокнот, сказав что если вложить дофига усилий можно получить офигенную конфетку, но к сожалению не могу пока предсказать из какой она будет субстанции — менеджмент почесал бошку и сказал ну его нафиг, давайте лучше дальше наши кривохаки пилить. А о том что такая модель безопасности вобщемто тянет на замену устоявшимся юникс пермишенам и даклам я вообще тогда промолчал, дабы совсем у виска не покрутили. А сейчас вот прочитав эту ветку — вспомнилось. Так что не надо ожидать что я прямо вот ща вам вывалю whitepaper на тыщу страниц и печатью ОТК за подписью Брюса Шнайера и ведущих специалистов по юзабилити.
Нет, зачем 1000 страниц. Достаточно внятно изложить идею — не просто "давайте пометим каждый байт", а на пальцах. Вот, скажем, идею PKI можно изложить в пяти абзацах так, чтобы стало понятно, каким образом решаются проблемы безопасной коммуникации. Ещё в трёх абзацах можно рассказать, чем от неё отличается PGP.
При этом не очень нужно вдаваться в детали реализации длинной арифметики на машинах с конечной разрядностью — эти важные для реализации детали несущественны для понимания идеи и её слабых/сильных мест.
O>Просто текущие системы безопасности NT/Unix тащат свои корни с лохматых времен с мэйнфреймами, на которых сидели различные пользователи, и каждый пользователь делал какую нибудь одну, но очень важную для него вещь. В таком окружении та модель замечательно работает: там пользователь == защищаемые данные. Проблема в том что сейчас ее пытаются натянуть на однопользовательское окружение, в котором куча разных данных, совершенно различными "степенями секретности", но все они варятся в едином котле одного уровня привилегий.
Проблема вовсе не в этом. Проблема, конечно же, в том, что в юниксовые времена пользователь == программам, с которыми он работает. Ситуацию, когда пользователь выполняет под своими привилегиями потенциально враждебную программу, авторы этих систем безопасности не рассматривали вообще.
Как раз всякие степени секретности по отношению к данным прекрасно моделируются в модели NT — она ж недаром проходила военную сертификацию.
Плохо моделируются степени секретности по отношению к коду.
Да, ваше решение сильно поможет авторам DRM и DLP — в нём тупой пользователь не сможет нечаянно переслать секретный документ получателю с более низким уровнем доступа.
При условии, естественно, что классификация документа выполнена правильно. В этом и состоит основная проблема — данных возникает очень много.
O>А разделить уровни — непонятно как, потому что просто нет прямого и естественного пути их перегруппировать, причем так чтоб потом еще и можно было шарить друг с другом. Опять же старая модель безопасности предполагала наличие админа, который бы всем настроил пермишены и сказал кому что можно, а кому что нельзя. В нынешней же солянке информации на типичной системе никакой админ не разберется, кроме того она постоянно меняется. Для защиты данных нужна новая модель безопасности, которая защищает именно данные, а не какието произвольные сущности которые с конкретными данными однозначно и на словах увязать то сложно, а не то что формально описать и запрограммировать.
Модель безопасности NT построена вокруг того, что было доступно на момент разработки. То есть вокруг securable object. Её легко расширить на произвольные securable objects.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Безопасность ОС. Можно ли решить кардинально?
S>Здравствуйте, ononim, Вы писали: O>>До сих пор вы задавали вопросы с очевидными ответами, тем не менее делая вид что не видите этих ответов. S>Пока что вы ни на один из них толком не ответили.
Да нет, я как раз таки ответил. А этот ваш комментарий-ярлык ровным счетом ничего не меняет.
S>Как я и полагал, у вас хорошо продуман нижний уровень, но нет ни малейшего представления о том, как из этого нижнего уровня собрать решение для пользовательских сценариев. Я сам таким изобретательством занимался в 19 лет
Это многое объясняет
O>>Просто текущие системы безопасности NT/Unix тащат свои корни с лохматых времен с мэйнфреймами, на которых сидели различные пользователи, и каждый пользователь делал какую нибудь одну, но очень важную для него вещь. В таком окружении та модель замечательно работает: там пользователь == защищаемые данные. Проблема в том что сейчас ее пытаются натянуть на однопользовательское окружение, в котором куча разных данных, совершенно различными "степенями секретности", но все они варятся в едином котле одного уровня привилегий. S>Проблема вовсе не в этом. Проблема, конечно же, в том, что в юниксовые времена пользователь == программам, с которыми он работает. Ситуацию, когда пользователь выполняет под своими привилегиями потенциально враждебную программу, авторы этих систем безопасности не рассматривали вообще. S>Как раз всякие степени секретности по отношению к данным прекрасно моделируются в модели NT — она ж недаром проходила военную сертификацию. O>>А разделить уровни — непонятно как, потому что просто нет прямого и естественного пути их перегруппировать, причем так чтоб потом еще и можно было шарить друг с другом. Опять же старая модель безопасности предполагала наличие админа, который бы всем настроил пермишены и сказал кому что можно, а кому что нельзя. В нынешней же солянке информации на типичной системе никакой админ не разберется, кроме того она постоянно меняется. Для защиты данных нужна новая модель безопасности, которая защищает именно данные, а не какието произвольные сущности которые с конкретными данными однозначно и на словах увязать то сложно, а не то что формально описать и запрограммировать. S>Модель безопасности NT построена вокруг того, что было доступно на момент разработки. То есть вокруг securable object. Её легко расширить на произвольные securable objects.
Дело не в том что они моделируются или не моделируются, дело в том что разработчики софта — ленивые люди по умолчанию, о безопасности они думают в последнюю очередь. С какой палкой над ними не стой — никто не станет создавать сэндбокс для каждого документа/сайта и парится о том чтоб его данные не утекли кудато не туда (в соседний документ например). Даже браузеры особо с этим не парятся, не говоря уж про всякие стимы из соседнего листа, которым лишь бы работало. Эта модель безопасности работает когда все участники ею правильно пользуются. Можно привести аналогию из прошлого — до появления вытесняющей многозадачности была кооперативная, которая работала только когда все ею правильно пользовались. Но было одно но — если ктото ею неверно пользовался — это было видно сразу, в отличии от системы безопасности, проблем в которой не видно пока банк не пришлет стейтмент с нулевым счетом. Поэтому я считаю что текущая модель безопасности устарела, как и устарела когда-то кооперативная многозадачность, и будущее за ОС которая будет прозрачно защищать _данные_, прозрачно — это значит без требования к программеру описывать секурити дескрипторы к каждому мутексу и файлмэпингу в своей программе. Эта самая моя предложенная модель — она как раз такая.
S>Плохо моделируются степени секретности по отношению к коду. S>Да, ваше решение сильно поможет авторам DRM и DLP — в нём тупой пользователь не сможет нечаянно переслать секретный документ получателю с более низким уровнем доступа. S>При условии, естественно, что классификация документа выполнена правильно. В этом и состоит основная проблема — данных возникает очень много.
Именно. Много данных, еще больше данных которые из них получается, граф взаимосвязи дико запутанный и никто за ним не следит вообще. ОС говорит — 'вот вам абстракции SD/token — накладывайте их на все ваши контейнеры данные', программеры — 'да ну нафиг, я лучше еще вот этот прочитанный вчера перед сном паттерн вверну и кнопочки сделаю в метрошном стиле'. Ни у кого нет конкретной ответственности — в результате бардак.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Дело не в том что они моделируются или не моделируются, дело в том что разработчики софта — ленивые люди по умолчанию, о безопасности они думают в последнюю очередь.
Правильно. О безопасности за них думают разработчики OC.
O>С какой палкой над ними не стой — никто не станет создавать сэндбокс для каждого документа/сайта и парится о том чтоб его данные не утекли кудато не туда (в соседний документ например).
Правильно. "Сэндбокс" создаёт админ — при помощи раздачи DACL на файлах. Это прекрасно работает в файловой системе, включая сетевые диски.
В правильно настроенной системе тупой пользователь не может дать доступ к секретному файлу другому тупому пользователю — потому что все ACL настроены админом.
O>прозрачно — это значит без требования к программеру описывать секурити дескрипторы к каждому мутексу и файлмэпингу в своей программе. Эта самая моя предложенная модель — она как раз такая.
Существующая модель уже и так не требует от программера никакого "описания секурити дескрипторов".
Про вашу модель вы пока рассказали только "вау", и никаких существенных деталей.
O>Именно. Много данных, еще больше данных которые из них получается, граф взаимосвязи дико запутанный и никто за ним не следит вообще. ОС говорит — 'вот вам абстракции SD/token — накладывайте их на все ваши контейнеры данные', программеры — 'да ну нафиг, я лучше еще вот этот прочитанный вчера перед сном паттерн вверну и кнопочки сделаю в метрошном стиле'. Ни у кого нет конкретной ответственности — в результате бардак.
А, я кажется понял. В вашей системе безопасность будет обеспечиваться тем, что все данные уже засекьюрены, и написать банальный grep невозможно — потому что он работает с заранее неизвестным списком источников, никто из которых не почешется добавить grep в список разрешённых получателей.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Безопасность ОС. Можно ли решить кардинально?
O>>Дело не в том что они моделируются или не моделируются, дело в том что разработчики софта — ленивые люди по умолчанию, о безопасности они думают в последнюю очередь. S>Правильно. О безопасности за них думают разработчики OC.
O>>С какой палкой над ними не стой — никто не станет создавать сэндбокс для каждого документа/сайта и парится о том чтоб его данные не утекли кудато не туда (в соседний документ например). S>Правильно. "Сэндбокс" создаёт админ — при помощи раздачи DACL на файлах. Это прекрасно работает в файловой системе, включая сетевые диски. S>В правильно настроенной системе тупой пользователь не может дать доступ к секретному файлу другому тупому пользователю — потому что все ACL настроены админом.
В том и проблема что в реальном мире
а) пользователь и данные — отдельные малопересекающиеся сущности
б) и хотя даклы это могут учесть, никто их правильно не настраивает.
Хорошая архитектура должна учитывать особенности суровой реальности, а не отстранятся от них в сферический вакуум.
O>>Именно. Много данных, еще больше данных которые из них получается, граф взаимосвязи дико запутанный и никто за ним не следит вообще. ОС говорит — 'вот вам абстракции SD/token — накладывайте их на все ваши контейнеры данные', программеры — 'да ну нафиг, я лучше еще вот этот прочитанный вчера перед сном паттерн вверну и кнопочки сделаю в метрошном стиле'. Ни у кого нет конкретной ответственности — в результате бардак. S>А, я кажется понял. В вашей системе безопасность будет обеспечиваться тем, что все данные уже засекьюрены, и написать банальный grep невозможно — потому что он работает с заранее неизвестным списком источников, никто из которых не почешется добавить grep в список разрешённых получателей.
Нет, вы ровным счетом ничего не поняли. В моей системе любому коду можно делать с любыми данными все что угодно, до тех пор пока они не пойдут "наружу". Если данным с которым работает греп можно выводится на экран — они будут выведены. Фактически она дает даже больше свободы разработчикам, нежели существующая архитектура.
Как много веселых ребят, и все делают велосипед...
Re[18]: Безопасность ОС. Можно ли решить кардинально?
Здравствуйте, ononim, Вы писали:
O>Нет, вы ровным счетом ничего не поняли.
Как объясняете — так и понял. O>В моей системе любому коду можно делать с любыми данными все что угодно, до тех пор пока они не пойдут "наружу". Если данным с которым работает греп можно выводится на экран — они будут выведены.
Каким волшебным образом данные поймут, что они выводятся на экран? Греп у нас выдаёт результат какому-то другому процессу, а тот — третьему, затем — четвёртому.
Какой-то из них действительно выводит на экран. Только не на тот, на который смотрит пользователь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Безопасность ОС. Можно ли решить кардинально?
O>>Нет, вы ровным счетом ничего не поняли. S>Как объясняете — так и понял.
O>>В моей системе любому коду можно делать с любыми данными все что угодно, до тех пор пока они не пойдут "наружу". Если данным с которым работает греп можно выводится на экран — они будут выведены. S>Каким волшебным образом данные поймут, что они выводятся на экран? Греп у нас выдаёт результат какому-то другому процессу, а тот — третьему, затем — четвёртому. S>Какой-то из них действительно выводит на экран. Только не на тот, на который смотрит пользователь.
Еще раз повторяю — освободите свой разум забудьте о процессах, это ненужная абстракция. Рассматривайте CPU+RAM как черный ящик, который принимает некоторые данные на вход через устройства ввода (сетевой интерфейс, умеющий отслеживать и верифицировать SSL соединения, клава, мышь etc), делает на ними некоторые преобразования, результатом которых являются некоторые другие данные и выдает результат на выход (монитор, принтер, тот же сетевой интерфейс etc..).
Теперь:
— мы научим устройства ввода помечать информацию метаданными о ее происхождении и разрешениях которые на нее накладываются источником ее происхождения. Для SSL подключения — это информация из сертификата, для устройств пользовательского ввода — это в идеале личный пользовательский сертификат, или хотябы некоторая уверенность в том, что это какой то определенный пользователь.
— мы научим наш черный ящик работать так, что на момент вывода им информации через любое из устройств вывода будет математически точно известно, что она является производным результатом того, некоторых данных, что пришли на вход
— теперь, мы можешь знать какие ограничения накладываются на эту информацию, что наш черный ящик пытается выплюнуть во внешний мир, а так же знаем куда именно он ее хочет выплюнуть, и можем разрешить ему это сделать либо не разрешить. Либо даже отправить некий аудит репорт в случае обнаружения попытки виолейшна.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Еще раз повторяю — освободите свой разум забудьте о процессах, это ненужная абстракция. Рассматривайте CPU+RAM как черный ящик, который принимает некоторые данные на вход через устройства ввода (сетевой интерфейс, умеющий отслеживать и верифицировать SSL соединения, клава, мышь etc), делает на ними некоторые преобразования, результатом которых являются некоторые другие данные и выдает результат на выход (монитор, принтер, тот же сетевой интерфейс etc..).
Конкретнее: какие данные, и что будет результатом преобразования. Пока что вы просто описываете фон-неймановскую архитектуру.
O>Теперь: O>- мы научим устройства ввода помечать информацию метаданными о ее происхождении и разрешениях которые на нее накладываются источником ее происхождения. Для SSL подключения — это информация из сертификата, для устройств пользовательского ввода — это в идеале личный пользовательский сертификат, или хотябы некоторая уверенность в том, что это какой то определенный пользователь. O>- мы научим наш черный ящик работать так, что на момент вывода им информации через любое из устройств вывода будет математически точно известно, что она является производным результатом того, некоторых данных, что пришли на вход
Давайте начнём с простого.
1. Вот у вас "данное" X, помеченное метаданными о ее происхождении и разрешениях. И "данное" Y, тоже помеченное метаданными о ее происхождении и разрешениях.
Какие метаданные и разрешения будут у (X+Y)?
2. Вот у вас клавиатура. Генерирует последовательности текста, помеченные личным пользовательским сертификатом. (Предположим, клавиатура умная и сама объединяет нажатия кнопок в тексты. А то вы явно не задумывались о том, как применить ЭЦП к, скажем, отдельному нажатию клавиши Shift).
Какие "разрешения" будут у этих последовательностей текста? Можно ли их передавать, скажем, в интернет? Если нет, то как мне, например, пользоваться Скайпом? Если да, то что помешает набранному мной номеру кредитки утечь к фродерам?
O>- теперь, мы можешь знать какие ограничения накладываются на эту информацию, что наш черный ящик пытается выплюнуть во внешний мир, а так же знаем куда именно он ее хочет выплюнуть, и можем разрешить ему это сделать либо не разрешить. Либо даже отправить некий аудит репорт в случае обнаружения попытки виолейшна.
"Мы" — это кто?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Безопасность ОС. Можно ли решить кардинально?
O>>Еще раз повторяю — освободите свой разум забудьте о процессах, это ненужная абстракция. Рассматривайте CPU+RAM как черный ящик, который принимает некоторые данные на вход через устройства ввода (сетевой интерфейс, умеющий отслеживать и верифицировать SSL соединения, клава, мышь etc), делает на ними некоторые преобразования, результатом которых являются некоторые другие данные и выдает результат на выход (монитор, принтер, тот же сетевой интерфейс etc..). S>Конкретнее: какие данные, и что будет результатом преобразования. Пока что вы просто описываете фон-неймановскую архитектуру.
Вообщето не только, гарвардская тоже прекрасно подпадает
O>>Теперь: O>>- мы научим устройства ввода помечать информацию метаданными о ее происхождении и разрешениях которые на нее накладываются источником ее происхождения. Для SSL подключения — это информация из сертификата, для устройств пользовательского ввода — это в идеале личный пользовательский сертификат, или хотябы некоторая уверенность в том, что это какой то определенный пользователь. O>>- мы научим наш черный ящик работать так, что на момент вывода им информации через любое из устройств вывода будет математически точно известно, что она является производным результатом того, некоторых данных, что пришли на вход S>Давайте начнём с простого. S>1. Вот у вас "данное" X, помеченное метаданными о ее происхождении и разрешениях. И "данное" Y, тоже помеченное метаданными о ее происхождении и разрешениях. S>Какие метаданные и разрешения будут у (X+Y)? S>2. Вот у вас клавиатура. Генерирует последовательности текста, помеченные личным пользовательским сертификатом. (Предположим, клавиатура умная и сама объединяет нажатия кнопок в тексты. А то вы явно не задумывались о том, как применить ЭЦП к, скажем, отдельному нажатию клавиши Shift). S>Какие "разрешения" будут у этих последовательностей текста? Можно ли их передавать, скажем, в интернет? Если нет, то как мне, например, пользоваться Скайпом? Если да, то что помешает набранному мной номеру кредитки утечь к фродерам?
А давайте вы сформулируете список вопросов, а я потом когда будет свободное время поразмыслю и сформулирую список ответов. Если конечно вам это правда интересно.
O>>- теперь, мы можешь знать какие ограничения накладываются на эту информацию, что наш черный ящик пытается выплюнуть во внешний мир, а так же знаем куда именно он ее хочет выплюнуть, и можем разрешить ему это сделать либо не разрешить. Либо даже отправить некий аудит репорт в случае обнаружения попытки виолейшна. S>"Мы" — это кто?
Я и Кернел
Как много веселых ребят, и все делают велосипед...
Re[22]: Безопасность ОС. Можно ли решить кардинально?
Здравствуйте, ononim, Вы писали:
S>>Давайте начнём с простого. S>>1. Вот у вас "данное" X, помеченное метаданными о ее происхождении и разрешениях. И "данное" Y, тоже помеченное метаданными о ее происхождении и разрешениях. S>>Какие метаданные и разрешения будут у (X+Y)? S>>2. Вот у вас клавиатура. Генерирует последовательности текста, помеченные личным пользовательским сертификатом. (Предположим, клавиатура умная и сама объединяет нажатия кнопок в тексты. А то вы явно не задумывались о том, как применить ЭЦП к, скажем, отдельному нажатию клавиши Shift). S>>Какие "разрешения" будут у этих последовательностей текста? Можно ли их передавать, скажем, в интернет? Если нет, то как мне, например, пользоваться Скайпом? Если да, то что помешает набранному мной номеру кредитки утечь к фродерам? O>А давайте вы сформулируете список вопросов, а я потом когда будет свободное время поразмыслю и сформулирую список ответов. Если конечно вам это правда интересно.
Вопрос, собственно, один: как это работает.
Поскольку никакого описания системы я не вижу, я не могу задать осмысленные вопросы к нему. Приходится спрашивать про те немногие вещи, которые вы упомянули.
Привычная нам низкоуровневая архитектура — это ассемблер, работающий с
а) кодом
б) данными.
При этом у нас более-менее всегда есть бинарные (реже — тернарные) операции, т.е. исходных данных у нас сразу два.
Допустим, теперь мы переходим от сырых данных к размеченным. Предположим, в общем духе фонНеймана, что код — это такие же данные, т.е. тоже оборудован разметкой.
Теперь нам надо для всех операций нашего ассемблера описать формулы, по которым получается итоговая разметка. Итоговые данные и так понятны — правила формирования результата imul [dest], eax придуманы до нас.
Велком — рассказывайте, какие операции вы собираетесь поддерживать, и как получается итоговая разметка.
Где-то в середине, очевидно, будет упоминание про те сочетания разметки исходных данных, при которых возникает AccessViolation.
А ближе к концу — упоминание про то, каким образом это собирается в замкнутую систему — что именно мешает злоумышленнику поставить свой апдейт в кернел.
O>Я и Кернел
Вот, заодно расскажете, что такое "Кернел".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Безопасность ОС. Можно ли решить кардинально?
S>>>1. Вот у вас "данное" X, помеченное метаданными о ее происхождении и разрешениях. И "данное" Y, тоже помеченное метаданными о ее происхождении и разрешениях. S>>>Какие метаданные и разрешения будут у (X+Y)? S>>>2. Вот у вас клавиатура. Генерирует последовательности текста, помеченные личным пользовательским сертификатом. (Предположим, клавиатура умная и сама объединяет нажатия кнопок в тексты. А то вы явно не задумывались о том, как применить ЭЦП к, скажем, отдельному нажатию клавиши Shift). S>>>Какие "разрешения" будут у этих последовательностей текста? Можно ли их передавать, скажем, в интернет? Если нет, то как мне, например, пользоваться Скайпом? Если да, то что помешает набранному мной номеру кредитки утечь к фродерам? O>>А давайте вы сформулируете список вопросов, а я потом когда будет свободное время поразмыслю и сформулирую список ответов. Если конечно вам это правда интересно. S>Вопрос, собственно, один: как это работает.
Пока никак, архитектура то гипотетическая Хотя хз конечно что творится в RND лабах IT гигантов и вояк. А моя практическая реализация была исключительно софтварно-эмуляторная и носила исключительно демонстрационный характер, и вообще не планировалась к развитию в том виде в котором начиналась. Но я ее опишу ниже.
S>Поскольку никакого описания системы я не вижу, я не могу задать осмысленные вопросы к нему. Приходится спрашивать про те немногие вещи, которые вы упомянули. S>Привычная нам низкоуровневая архитектура — это ассемблер, работающий с S>а) кодом S>б) данными. S>При этом у нас более-менее всегда есть бинарные (реже — тернарные) операции, т.е. исходных данных у нас сразу два. S>Допустим, теперь мы переходим от сырых данных к размеченным. Предположим, в общем духе фонНеймана, что код — это такие же данные, т.е. тоже оборудован разметкой. S>Теперь нам надо для всех операций нашего ассемблера описать формулы, по которым получается итоговая разметка. Итоговые данные и так понятны — правила формирования результата imul [dest], eax придуманы до нас. S>Велком — рассказывайте, какие операции вы собираетесь поддерживать, и как получается итоговая разметка.
Любая операция принимает на вход некие данные, делает над ними некие вычисления, результат которых зависит от самой операции и от входных данных. В результате операции появляются новые данные. Причем совершенно независимо от того что там за операция — imul, xor или SSEэшное перемножение векторов, 'принадлежность' информации которая получается в ее результате однозначно определяется как объединение принадлежностей информации принимаемой на вход (всех операндов, включая регистры и IO порты) и самой операции.
S>Где-то в середине, очевидно, будет упоминание про те сочетания разметки исходных данных, при которых возникает AccessViolation.
'AccessViolation' будет возникать исключительно на границе с внешним миром, то есть при выводе информации за пределы зоны, где мы можем отслеживать ее родословную вышеупомянутым методом.
Объясню как это будет работать: к примеру у вас есть банковский сайт. Банковский сайт не хочет чтобы
1) данные которые он предоставит юзеру ушли куда либо, кроме юзера и банковского сайта
2) чтобы к нему пришли некоторые данные, которые сформированные третьей стороной
Это значит, что в своем ssl сертификатей банк указывает, что
1) информация, которая пришла с него в нашу систему оттуда может уйти только на
1.а) сам банковский сайт
1.б) класс устройств вывода "дисплей"
1.в) класс устройств вывода "принтер"
2) информация, которая будет отправлятся в банк, не должна иметь в родословной никого кроме
2.а) самого банка
2.б) устройств пользовательского ввода (клава, мышь, сканер днк
2.в) информации, пришедшей с других источников, сертифицированных для работы с финансами. Либо даже жестче — информации единственным родителем которой, является исключительно производитель браузера.
Теперь попробуйте придумать вектор атаки, которая это обойдет. Причем заранее попробую порвать вам шаблон — успешная атака это не то что "ура-ура-ура, мой малвар прочитал секретные данные себе в буфер и нарисовал пользователю кукиш". Успешная атака — это преодоление тех пунктов, которые помечены как 'чего не хочет банк'.
Вопрос наличия ошибок кода самой системы трекинга оставим в стороне. Я уже писал что серебряных пуль не бывает, и в любой системе может найтись ошибка.
S>А ближе к концу — упоминание про то, каким образом это собирается в замкнутую систему — что именно мешает злоумышленнику поставить свой апдейт в кернел.
Код супервизора, отслеживающий все это должен защищаться по старинке — ring0, ring3.
O>>Я и Кернел S>Вот, заодно расскажете, что такое "Кернел".
Поскольку кернела еше нет, рассказывать осбо нечего, кроме той демонстрашки про которую я рассказывал. Расскажу про демонстрашку. Повторюсь — она лишь эксперимент, ставящий перед собой оценку effort разработки продукта на основе такой технологии, а не самого продукта. То есть код делался на коленке с целью поиграться и выбросить. Цель была — открыть тестовым приложением несколько файликов, после чего тестовое приложение должно было "перемешать" данные некоторых файликов и сохранить новый файлик. И чтобы про новый файлик было известно что его содержимое составлено из таких то исходных файликов. Код делал следующие вещи:
1) запускал target процесс с инжектом себя родимого в него прежде чем его код начинал исполнятся
2) проинжекченная часть первым делом расставляла хуки на все возможные точки начала исполнения пользовательского кода процесса: KiUserApcDispatcher, KiUserCallbackDispatcher, KiUserExceptionDispatcher, KiRaiseUserExceptionDispatcher. Что это за точки — понятно из названия, а подробности можно узнать в исходниках windows research kernel в файле wrk-v1.2\base\ntos\ps\kulookup.c. Так же она перехватывала многие системные сервисы предоставляемые через ntdll и user32.
3) При помощи hardware breakpoints она делала трейсинг (по-инструкционное исполнение) кода каждого потока, который стартовался апликухой (акаждый поток начинает жить с KiUserApcDispatcher). Делала просто — при помощи distorm disassembler декодировала длину каждой инструкции и переставляла бряк вперед, либо если инструкция — джамп/колл — ставила бряки туда, куда он мог попасть. Далее — для многих инструкций (но не всех напомню) я сделал метаописание типа откуда они что берут и куда кладут. Эта часть была не доделана, поскольку инструкций много, а я один. Но делала она следующее — доставала из своей базы метки каждого из входных операндов, объединяла их и складывала в выходной операнд. Регистры, память — все это операнды. Для некоторых (но далеко не всех) системных функций были таким же образом описаны их параметры, просто согласно их документации. Таким образом вызов msvcrt!memcpy вовсе необязательно было трекать целиком, ведь известно что все что она делает — копирует n байт копируются из src в dst.
Это все понятное дело УЖАСНО тормозило. Несмотря на то что я многие системные функции описал как ничего не делающие — прорисовка калькулятора и ноутпада длилась десятки секунд
НО прелесть этого подхода — то что в плане производительности он масштабируется практически неограниченно: умный анализатор может динамически анализировать последовательности инструкций, автоматически строя трассируемые единицы кода крупнее чем одна инструкция. Кроме того управляемые языки в силу своей специфики должны быть гораздо более приспособлены к таким махинациям нежели x86 код.
Но все это очень сложно. Как я уже написал — я честно сказал нашим что будет песец как сложно сделать так чтоб работала не тестовая апликуха, а офисное приложение и эту идею забросили. И сам я ею не занимался с тех пор потому что прекрасно понимаю что effort там такой, что у меня пупок развяжется. Потому и выложил эту идею здесь — авось спецы из интеля почитывают рсдн и запилят такую архитектуру. А мне что — я властвовать миром не рвусь, а вот от того что мою идею заимплементят — приятно было бы Вероятность этого конечно так же близка к нулю, но таки выше чем то что я сам это сделаю.
Как много веселых ребят, и все делают велосипед...
Re[24]: Безопасность ОС. Можно ли решить кардинально?
Здравствуйте, ononim, Вы писали:
O>Любая операция принимает на вход некие данные, делает над ними некие вычисления, результат которых зависит от самой операции и от входных данных. В результате операции появляются новые данные. Причем совершенно независимо от того что там за операция — imul, xor или SSEэшное перемножение векторов, 'принадлежность' информации которая получается в ее результате однозначно определяется как объединение принадлежностей информации принимаемой на вход (всех операндов, включая регистры и IO порты) и самой операции.
Ок. Давайте я догадаюсь: а разрешения, очевидно, будут определяться как пересечение разрешений исходных операндов.
S>>Где-то в середине, очевидно, будет упоминание про те сочетания разметки исходных данных, при которых возникает AccessViolation. O>'AccessViolation' будет возникать исключительно на границе с внешним миром, то есть при выводе информации за пределы зоны, где мы можем отслеживать ее родословную вышеупомянутым методом. O>Объясню как это будет работать: к примеру у вас есть банковский сайт. Банковский сайт не хочет чтобы O>1) данные которые он предоставит юзеру ушли куда либо, кроме юзера и банковского сайта O>2) чтобы к нему пришли некоторые данные, которые сформированные третьей стороной O>Это значит, что в своем ssl сертификатей банк указывает, что O>1) информация, которая пришла с него в нашу систему оттуда может уйти только на O>1.а) сам банковский сайт O>1.б) класс устройств вывода "дисплей" O>1.в) класс устройств вывода "принтер" O>2) информация, которая будет отправлятся в банк, не должна иметь в родословной никого кроме O>2.а) самого банка O>2.б) устройств пользовательского ввода (клава, мышь, сканер днк O>2.в) информации, пришедшей с других источников, сертифицированных для работы с финансами. Либо даже жестче — информации единственным родителем которой, является исключительно производитель браузера.
O>Теперь попробуйте придумать вектор атаки, которая это обойдет.
Основной вектор простой: пользователь совершенно добровольно сносит эту систему и ставит такую, в которой можно работать.
Потому что кому нафиг нужен банковский сайт, который отказывается принимать данные, которые я скопировал из письма от моего ТСЖ, со словами "неподтверждённый источник".
Я, получается, должен руками перебивать все эти реквизиты. Сразу порву вам шаблон: надежда на то, что моё ТСЖ получит в вашей системе "сертификацию как источника информации, разрешённого для работы с финансами", призрачна. Потому что иначе вектором атаки станет ТСЖ.
O>Причем заранее попробую порвать вам шаблон — успешная атака это не то что "ура-ура-ура, мой малвар прочитал секретные данные себе в буфер и нарисовал пользователю кукиш". Успешная атака — это преодоление тех пунктов, которые помечены как 'чего не хочет банк'.
Ок, давайте предположим на минуту, что кто-то с ножом у горла таки заставил пользователей жить с навязанной вами епитимьей.
Без проблем — вы решили игнорировать то, что происходит внутри системы. Это значит, что ничто не помешает трояну зарегистрироваться как "драйвер дисплея", и прекрасно передавать данные куда он хочет.
S>>А ближе к концу — упоминание про то, каким образом это собирается в замкнутую систему — что именно мешает злоумышленнику поставить свой апдейт в кернел. O>Код супервизора, отслеживающий все это должен защищаться по старинке — ring0, ring3.
Ну, как мы знаем из опыта, ring0, на который в 1988 возлагали столько надежд, себя не оправдал. Понятие "руткит" вам знакомо?
O>Но все это очень сложно. Как я уже написал — я честно сказал нашим что будет песец как сложно сделать так чтоб работала не тестовая апликуха, а офисное приложение и эту идею забросили. И сам я ею не занимался с тех пор потому что прекрасно понимаю что effort там такой, что у меня пупок развяжется. Потому и выложил эту идею здесь — авось спецы из интеля почитывают рсдн и запилят такую архитектуру. А мне что — я властвовать миром не рвусь, а вот от того что мою идею заимплементят — приятно было бы Вероятность этого конечно так же близка к нулю, но таки выше чем то что я сам это сделаю.
Пока что видна чудовищная стоимость с отрицательным выхлопом: безопаность ничуть не улучшается, а геморроя пользователям на порядок больше.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Безопасность ОС. Можно ли решить кардинально?
Здравствуйте, Sinclair, Вы писали:
S>>>А ближе к концу — упоминание про то, каким образом это собирается в замкнутую систему — что именно мешает злоумышленнику поставить свой апдейт в кернел. O>>Код супервизора, отслеживающий все это должен защищаться по старинке — ring0, ring3.
S>Ну, как мы знаем из опыта, ring0, на который в 1988 возлагали столько надежд, себя не оправдал. Понятие "руткит" вам знакомо?
Ксати — Сейчас уже дальше зашли. В процессор. Там это пока не придумали как называется — ну типа не руткит же "-1".
Обидно что сертификаторы что-то там сертифицируют в софте и создают ложную иллюзию у потребителей, что типа тут закладок нет.
Как пробиться к тому кто понимает (поймет) что проблема атомная, ни как не удается. Ну мне покрайней мере.
). Натайпанные юзером данные автоматом будут считать произведенными юзером и иметь соответствующие разрешения. Но вот касательно этих разрешений есть ньюанс:
