Здравствуйте, WolfHound, Вы писали:
WH>И теперь расскажи, как через это пролезет вирь?
Все известные мне витки спирали "вот теперь-то мы построили 100% защищённую систему" были основаны на одном и том же принципе: искусственное сужение понятия "малварь" до удобного авторам.
Например, уже 20 лет в стандартных гражданских ОС у процесса нет никакой возможности "испортить память" чужого процесса. Увы — 19 лет назад оказалось, что то определение вируса, с которым боролись в intel и вокруг, никому не интересно. Безо всякой порчи памяти чужого процесса вирусы приносят значительный ущерб, даже веся 20 мегабайт и будучи написанными на VBA.

Теперь у нас есть система, в которой in-proc компонент не может испортить память даже в пределах одного процесса. Ну и что?

Сегодня наш вирус — это приложение фейсбука, которое спамит рекламой себя и инжектируемого сервиса всю твою адресную книгу. При этом ему не нужен ни доступ к памяти, ни к железу, ни к чему вообще. Оно прекрасно работает в самых жостких сэндбоксах. И с точки зрения разработчика оси, оно вообще вирусом не является. Ну исполняется там какой-то js в html5-приладе. Ну мимикрирует оно под приложение альфа-банка. Ну тырит деньги со счёта пользователя. Ведь главное-то — файлы в system32 — остаётся неиспорченным, и даже непрочитанным!

Поэтому у меня крайне пессимистичные ожидания в этом направлении.

S>>Велком — рассказывайте, какие операции вы собираетесь поддерживать, и как получается итоговая разметка.
O>Любая операция принимает на вход некие данные, делает над ними некие вычисления, результат которых зависит от самой операции и от входных данных. В результате операции появляются новые данные. Причем совершенно независимо от того что там за операция — imul, xor или SSEэшное перемножение векторов, 'принадлежность' информации которая получается в ее результате однозначно определяется как объединение принадлежностей информации принимаемой на вход (всех операндов, включая регистры и IO порты) и самой операции.

В примере перечислено то, что покроет 95% случаев. А вот специальные 5% инструкций доставят 95% проблем. И эти 5% — условные переходы. Вот как вы собираетесь размечать результат инструкции условного перехода? Все данные после перехода будут помечены тегом данных, которые использовались в условии? А не учитывать условные переходы нельзя, иначе можно создавать информацию из воздуха.

var bankBits = bankData.asLongNumber(); //банковые данные
var myData = 0; //хакерские данные.

for (var i = 0; i < 10000; i++) {
  if (bankBits % 2 == 0)
    myData = myData * 2; //только хакерские данные
  else
    myData = myData * 2 + 1; //тоже хакерские данные

  // Чисто банковские данные. Или нет? Хотя не важно.
  bankBits /= 2;
}
myData.reverseBits();

Вот так на условных переходах теги теряются. Так что нужно бы все условные переходы трейсить и навешивать теги от условия перехода. Чую, так просто от этого не отделаться будет. Расползутся теги от условного перехода по всему приложению. Вот посмотрит браузер на clipping area для вывода чего-нибудь со странички банка, и все, на всем UI-выводе будет висеть тег этого банка. Даже после того, как я закрыл все окна от него.

Еще интересные темы с межпроцессным взаимодействием. Как тегируется новый процесс?

O>Теперь попробуйте придумать вектор атаки, которая это обойдет.

Запросто. И даже теги на IP (instruction pointer) нам не помешают. Будем неторопясь сливать данные в свой "хакерский" домен. Отсутствие информации тоже может быть использовано в качестве информации!

// То, что мы хотим украсть (файл/буфер в памяти).
// Банковский тег на данных. 
// var bankBits = ...;

// Заведомо достаточно для данных, теги на некоторых ячейках будут меняться.
// Заполнен false'ами с хакерскими тегами.
var hLargeBuffer = new boolean[QUITE_BIG_BUFFER]; 

// Наш файл, в который мы пишем. Для простоты пишем биты, хакерский тег.
var hFile = openBitStream(...);

// Хакерские данные. Обязательно без банковского тега.
var hNextWriter = 0;

// Украсть банковские данные.
def stealData() {
  for (var i = 0; i < QUITE_BIG_BUFFER; i++)
    startThread(new KamikazeWriter(i).write);
  for (var i = 0; i <= QUITE_BIG_BUFFER; i++)
    startThread(new KamikazeReader(i).write);
  //Позапускали каких-то потоков. Вроде бы все локально.
}


//Райтер данных из банка. Писатель хакерского буфера.
class KamikazeWriter(pos : Int) {
  def write() = { 
    // на бите будет банковский тег.
    val bit = bankBits.getBitAt(pos); 
    if (bit == 1)
      hLargeBuffer[pos] = true;
    // на hLargeBuffer[pos] будет банковский тег, но только если
    // бит в позиции pos был установлен в 1. Иначе на 
    // hLargeBuffer[pos] не будет банковского тега (мы в него не пишем).
    // При необходимости массив можно развернуть в гору отдельных переменных.
    // Ячейки массива можно заменить на atomic для обеспечения потокобезопасности.
  }
}

//Читатель данных из буфера. Пишет в наш файл очищенные от тегов данные.
class KamikazeReader(order : Int) {
  def write() = {
    //Спим. Интервал должен быть достаточен, чтобы даже с погрешностями
    //планировщика читатели выполнялись в порядке order.
    Thread.sleep(order * SUFFICIENT_INTERVAL);
   
    // Предыдущий читатель наткнулся на коварно установленный банком бит
    // и погиб смертью храбрых защищая чистоту hNextWriter. Почтим память
    // того читателя установкой бита в наших чистых данных.
    if (hNextWriter < order)
      hFile.writeBit(1);
    
    // Пытаемся скопировать свой бит в хакерский файл.
    if (hLargeBuffer[order]) {
      // Все пропало. На нас теперь будет
      // проклятье банковских данных. Оно будет преследовать наш
      // Instruction Pointer до самой смерти. Так что умрем прямо сейчас.
    } else {
      // А бит был false. Это значит, на нем не было метки банка 
      // (мы не пишем false после чтения данных банка). И наш
      // Instruction Pointer еще не имеет ненужных тегов.
      hFile.writeBit(0);
      // Сигналим следующему читателю, что мы живы и единичку писать не надо.
      hNextWriter = order + 1;
    }
  }
}

Вот вам и вектор. Каждый читатель получает информацию из "хакерских данных". Если вдруг он прочитал данные с банковским тегом, он просто умирает (ничего никуда не сигналя!). Так как другие читатели знают протокол обмена, они могут восстановить "ошибки протокола" (т.е. не вышедших на связь в нужное время читателей).
Немного черной магии и данные извлекаются из "отсутствия данных". Чтобы с этим бороться, нужно либо анализировать как-то program flow и возможные affected vairables. Либо радостно развешивать теги на все псевдоглобальное, включая thread.sleep, сетевые взаимодействия и прочие источники, которые могут быть использованы для кражи данных. Но даже там я реализую sleep через большой цикл. И буду с интервалом ридеров пускать, а не ждать в самом ридере.

Что-то мне кажется, что попытки бороться со всем этим приведут к решению "ставим теги на процесс". А это уже совсем не так интересно. Плюс результат будет похож на то, что уже есть сейчас. Всякие apparmor и прочие ограничители прав приложений (т.е. не только файловый доступ, а еще сокеты, системные ресурсы и т.п.).

Форум "философия", ... пофилосовствуем на тему — Можно ли как-то принципиально, раз и на всегда решить ворос безопасности?

Какие тут есть проблемы:
1) Вирусы
2) Трояны
3) Разграничение

Проблема "Вирусы", это в первую очередь распостранение, можно ли как то в принципе придумать так чтобы вирусы не могли распостраняться?
Проблема "Трояны", это проблема скрытного выживания программы в системе, можно ли как-то придумать так чтобы скрытно сущуствовать в системе было невозможно?
Проблема "Разграничение", это даже не проблема, а отдельная большая тема — тут ее лучше не рассматривать.

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

ОС создается людьми с нуля, почему тут таже проблема — почему не придумали ( а может можно ) такую архитектуру что бы вирусы и трояны не могли бы быть созданы в принципе.

Ну вот тут при проектировании архитекрутры обычно применяют разные методы для для решения проблем — вот скажем есть "проблема" заражения исполняемого файла, тут чтобы закрыть проблему можно просто 1) Убрать такое понятие как исполняемый файл. 2) Сделать его на всегда только чтение — ну по аналогии с ROM. В ПЗУ файл вирусом не заразишь.

Вот предлагаю думать/по рассуждать на эту тему.

Тему специально тут завел а не в ИБ форуме, так как тут скорее именно мозговой штурм и философия, чем ИБ.

Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>>Проблема "Вирусы", это в первую очередь распостранение, можно ли как то в принципе придумать так чтобы вирусы не могли распостраняться?
WH>Verve OS

Что именно в Verve помешает распространяться вирусам? o_O

AWW>>Проблема "Трояны", это проблема скрытного выживания программы в системе, можно ли как-то придумать так чтобы скрытно сущуствовать в системе было невозможно?
WH>Достаточно заставить все приложения устанавливаться в персональную песочницу.

...и обеспечить их взаимодействие с ОС и друг с другом. И вот тут-то и начинается самое интересное

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Форум "философия", ... пофилосовствуем на тему — Можно ли как-то принципиально, раз и на всегда решить ворос безопасности?

Раз и навсегда нельзя, но можно устранить целые классы уязвимостей.

Чего принципиально убрать нельзя — это уязвимость через социальную инженерию.
Грубо говоря, если экран браузера залить красным цветом, написать большими буквами "Опасность! Срочно введите пароль от кредитки, иначе ядерная война!" — то даже на это какой-то процент людей поведется.

AWW>Проблема "Вирусы", это в первую очередь распостранение, можно ли как то в принципе придумать так чтобы вирусы не могли распостраняться?

1) Запрет на динамическую загрузку исполняемого кода, весь исполняемый код находится в одном месте (репозитории).
2) Верификация всего исполняемого кода.
3) Capability-based security — никакая программа не может дать прав другой программе больше, чем сама имеет.

AWW>Проблема "Трояны", это проблема скрытного выживания программы в системе, можно ли как-то придумать так чтобы скрытно сущуствовать в системе было невозможно?

Если система скомпрометирована (например, бинарный образ физически заменен на подпатченный) — то ничего сделать нельзя.
Нужно что-то типа аппаратного верификатора ядра системы — носишь флешку с собой, а на ней БИОС и верификатор. Как ключ в машине.

AWW>Проблема "Разграничение", это даже не проблема, а отдельная большая тема — тут ее лучше не рассматривать.

По поводу разграничений — надо запретить из под одного аккаунта делать действия типа "ходить в интернет" и "форматировать диск".
Ни один супер-администратор не должен иметь такую возможность. Один тип аккаунта может ТОЛЬКО форматировать диск, а другой — ТОЛЬКО ходить в интернет.
Т.е. должны быть группы типа "Пользователь компьютера", "Администратор дисков", "Администратор разграничения доступа" и т.п.

AWW>ОС создается людьми с нуля, почему тут таже проблема — почему не придумали ( а может можно ) такую архитектуру что бы вирусы и трояны не могли бы быть созданы в принципе.

Легаси-код. В случае виндовс местами еще и подход "security through obscurity", ибо никто не запрещает программам срать в реестр тысячами ключей, которые не удаляются при деинсталляции и потом используются для валидации срока пробной версии.

AWW>>>Проблема "Трояны", это проблема скрытного выживания программы в системе, можно ли как-то придумать так чтобы скрытно сущуствовать в системе было невозможно?
WH>>Достаточно заставить все приложения устанавливаться в персональную песочницу.
KV>...и обеспечить их взаимодействие с ОС и друг с другом. И вот тут-то и начинается самое интересное
Да-да. Пользователи, как ни странно, удобства хотят — открывать вордом документы скачанные в браузере и таскать картинки из ворда в скайп. Причем без тыщи подтверждений и проверок, а так чтоб просто работало.

Здравствуйте, Abyx, Вы писали:
A>вот приложение
A>

A>scriptName = input()
A>scriptText = open(scriptName).read()
A>eval(scriptText)
A>

A>расскажи что ты будешь тут подписывать, и как это поможет.
приложение буду подписывать. Если потом окажется, что оно исполняет злонамеренные скрипты, то мы отзовём сертификат автора, а автора показательно покараем анально.
В следующий раз он не будет скармливать текст из неизвестного источника в функцию eval().

Но в целом сочетание идей CAS и CBS позволяют защищать и такие вещи. В частности, внезапно окажется, что порождённый приложением код выполняется под правами приложения, т.е. не может делать ничего нового по сравнению с приложением. Если приложению нельзя было открывать соединение по протоколу IRC, то и сгенерированному в нём коду будет нельзя.

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

M>>Вот так на условных переходах теги теряются. Так что нужно бы все условные переходы трейсить и навешивать теги от условия перехода. Чую, так просто от этого не отделаться будет. Расползутся теги от условного перехода по всему приложению. Вот посмотрит браузер на clipping area для вывода чего-нибудь со странички банка, и все, на всем UI-выводе будет висеть тег этого банка. Даже после того, как я закрыл все окна от него.
O>Почему на всем UI выводе?
А так принято в типичной архитектуре на данный момент. Есть UI-поток, в котором выполняются все операции с графикой. И стоит ему сделать что-нибудь условное (например, прочитать атрибут Visible на каком-нибудь виджете, зависящий от данных банка) и все — на IP есть тег. Скорее всего, очистка тега при выходе из метода поможет бороться с этой проблемой. Что-то подобное может быть и внутри видео-драйверов, например.


M>>Еще интересные темы с межпроцессным взаимодействием. Как тегируется новый процесс?
O>Сущность 'процесс' ортогональна тегированию. Вкратце — советую вам в этом контексте про процессы забыть.
Зачем забывать? Они связаны все с тем же специальным случаем: регистром IP. Набор инструкций для него очень специфичен и очень сильно отличается от инструкций работы с другими регистрами и памятью. Как минимум нужно рассматривать, что с ним происходит при создании нового процесса (наследуется или нет). Этот связано с удобством разработки и использования. И именно на межпроцессное взаимодействие я буду смотреть в первую очередь для поиска способов очистить данные от тегов.
Плюс с процессами/потоками связаны некоторые вещи, которые очень сложно смоделировать в модели "функциональная зависимость от данных". Например, зависимость от текущего времени (таймауты, таймеры). С обычной памятью и кодом (при линейном потоке выполнения) проблем как раз нет. Но "текущая точка выполнения программы" тоже является очень важными данными, через которую я и буду атаковать. Банальное "я закрыл сокет за минуту" и "я не закрывал сокет больше двух минут" может служить для передачи бита данных. Кстати, обратите внимание, даже _закрытие_ сокета является передачей данных. Не проблема, но интересный момент.


M>>Немного черной магии и данные извлекаются из "отсутствия данных". Чтобы с этим бороться, нужно либо анализировать как-то program flow и возможные affected vairables. Либо радостно развешивать теги на все псевдоглобальное, включая thread.sleep, сетевые взаимодействия и прочие источники, которые могут быть использованы для кражи данных. Но даже там я реализую sleep через большой цикл. И буду с интервалом ридеров пускать, а не ждать в самом ридере.
O>Код не разбирал, не очень есть время на это сейчас, отвечу по изложенному тексту.
O>Теги навешиваются на все, на самом низком уровне Прыгая по дереву абстракций вверх — от них не спрячешься.

Буду ждать, пока разберете. И теги не помогут Попробую пояснить, что за трюк там используется на более простом примере.

// Общая переменная.
var a : Int = 0;

// Где-то в коде:
if (condition) {
  a = 1;
}
// Интересное место, какие там теги и данные в a ?!
print(a);

Забавные вещи начинаются в момент печати a. Допустим, я вижу в результате печати 0. Вопрос — а зависело ли это значение от conditional или нет? Формально — не зависело. Не писалась она после условия, только читалась. А с точки зрения здравого смысла — зависела! Если бы condition было true, было бы напечатано 1.
Теперь допустим кто-то (не пользователь) читает a. Допустим, он видит там 0. Какую информацию он имеет? Если там 0, то condition был false. Но в качестве бонуса он знает еще, что на a нет тегов от condition! Поэтому можно смело делать любые действия. Если же там 1-ка, то condition был true, но на нас уже есть теги от condition. Это уже не проблема, ведь что-то подобное мы делали при записи a, сделаем то же самое и в этом случае:

//Переменная для результата
var b : Boolean = true;

if (a == 0) {
  b = false;
}
print(b);

Все почти так же. Теперь b == condition и ее можно где-то читать. При этом на b заведомо нет тегов от condition. Да, остаются вопросы о том, как обеспечить последовательность выполнений двух примеров и следующего читателя. Если контекст очищается при вызове метода, можно просто три метода последовательно вызывать. Если же IP не очищается при возврате из метода (или условного вызова), нужно смотреть межпроцессорное/межпоточное взайимодействие. Там я буду использовать глобальное время для обеспечения нужной последовательности. Ну и вообще любой способ обеспечить "последовательность выполненя" будет потенциальным вектором атаки.

Получается, что для учета "зависит ли значение от другого значения" (в императивной модели) нужно знать не только те команды, которые выполнились, но и те, которые _не выполнились_ (но могли выполниться). Иначе мы можем "частично очищать данные".

Решение этой проблемы тоже есть. Нужно отказываться от изменяемых переменных и писать в чисто функциональном стиле. Причем вообще без исключений. Т.е. нам нужен haskell или что-то подобное с монадами для представления явной зависимости данных от "последовательных действий". Причем, похоже, это нужно делать на уровне всей системы. Т.е. IO должен быть глобальным для компьютера (системы), а не для одного процесса. Иначе я вместо записи бита в переменную будт создавать или не создавать файл. А другой процесс будет проверять наличие файла.

M>>Что-то мне кажется, что попытки бороться со всем этим приведут к решению "ставим теги на процесс". А это уже совсем не так интересно. Плюс результат будет похож на то, что уже есть сейчас. Всякие apparmor и прочие ограничители прав приложений (т.е. не только файловый доступ, а еще сокеты, системные ресурсы и т.п.).
O>Вообще моя предполагаемая архитектура если она имплементиться в хардваре — должна тегировать физическую память. Вообще всю, каждый байтик должен быть учтен.
А вопрос даже не в том, как это реализовать. Нужно показывать, что это стоит реализовывать. У меня есть сильные подозрения, что после открытия файла теги с этого файла распространятся по 90% приложения (через Instruction Pointer или IO monad) в течение пары минут. При такой скорости распространения практического смысла в тегировании каждой ячейки памяти нет, можно сразу на приложение вешать теги (да, да IP очень мешает). Поэтому нужно показывать, что можно сделать такую архитектуру, в которой можно эффективно ограничивать область распространения тегов. Это должно быть практично, причем как для маленьких приложений, так и для больших. Во всех разных моделях (UI, сервер и т.п.).

P.S. Забавный сценарий для размышления. Я кладу на экран две кнопки (в одно и то же место). В зависимости от условия, я убираю первую или вторую кнопку. В какой-то момент пользователь нажимает оставшуюся кнопку и я получаю информацию о том, какое же было значение. Формально идет только пользовательский ввод. Поможет ли здесь тегирование и если поможет, то как? (Вот так и появится тег данных на всем UI, как я и предполагал выше). А если это в виде игры оформить, вообще круто будет! Пользователь в процессе игры будет нам данные от тегов очищать. Процесс передачи system->user->system.

S>>>>>Поэтому у меня крайне пессимистичные ожидания в этом направлении.
O>>>>Нужно эффективное тегирование памяти. Чтоб точно трекать происхождение каждого байта, имеющегося в системе. Ведь любая имеющаяся на компе информация — она либо введена юзером, либо взята извне. Соответственно если пометить лейблой каждый байт, можно будет отследить его родословную и принять решение при выходе этой информации за пределы компа — выпускать ее или нет.
S>>>Вы прежде чем педалить — ответьте в общих чертах, каким образом это вообще поможет бороться с малварью?
O>>Очень просто — данные пришедшие с сайта Х не будут отправлены ни на какой сайт кроме того куда Х разрешил.
S>Хм. Ну вот, например, у меня сайт X — это фотошоп онлайн. Я правильно понимаю, что картинки, наредактированные этим сайтом, нельзя девать никуда, кроме жёстко прошитого списка сайтов?
S>Т.е. на facebook.com можно, а на facebook.ru — уже нельзя?
Ну вот зачем сразу утрировать и пытаться свести к абсурдности? В стандартном DACL вы тоже перечисляете всех и каждого или там еще группы есть?

S>>>В этом контексте задача по защите системных файлов решается вообще с полпинка — просто тегируем их информацию как не подлежащую изменению информацией ничьей, кроме источника microsoft.com.
O>>Это отчасти так. Но лишь отчасти — данные в памяти таки кучкуются, и хранить лейблы лучше будет не per-byte, а per-region. Примерно так же, как сейчас организуется виртуальная память. Мегабайт тоже перебор — ассоциированное с памятью значение будет лишь уникальным идентификатором указывающим в некую базу, источников данных на самом деле не так уж много, вполне хватит, если идентификатор каждого будет дворд, то в мегабайт влезет 412144 источников. Вы уверены что у вас столько уникальных сайтов в хистори наберется?
S>А у кого будут права на запись в базу идентификаторов?
У ядра оси, разумеется. Тут — полная аналогия с системой виртуальной памяти.
Заранее сразу отвечаю на пару вопросов:
1) Ядро оси никто не сможет модифицировать, окромя тех кому можно (а можно — информации, созданной производителем оси).
2) ДА. Это получится очень анально огороженная архитектура.
3) _Можно_ развить концепцию до еще более анально огороженной trusted hardware platform:
3.а) Писать в базу идентификаторов сможет только железо (зашитая в нем фирмварь)
3.б) Сетевые адаптеры должны аппаратно поддерживать SSL. Любая входящая по сети информация должна автоматически тегироваться группами, прописанными в сертификате другой стороны. Если не SSL — значит группа anonymous.
3.в) У пользователя системы должен быть личный сертификат, с помощью которого клава/мышь/тач так же будут тегировать весь его ввод, с возможностью криптографической его верификации в случае необходимости (банковская транзакция, заказ авиабилета, пост в КЫВТ...)

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Проблема "Вирусы", это в первую очередь распостранение, можно ли как то в принципе придумать так чтобы вирусы не могли распостраняться?

Чем вирус отличается от других программ? Проблему можно решить, если ограничить набор программ для установки. Например, только из AppStore. Ну а так всегда будет возможна ситуация, что пользователь хочет установить некоторую программу, а ему не дают.

AWW>Проблема "Трояны", это проблема скрытного выживания программы в системе, можно ли как-то придумать так чтобы скрытно сущуствовать в системе было невозможно?

Можно, если не работать под root. Опять же, ряд приложений вполне можна рассматривать как аналоги операционки. Например, Firefox и в нем addon.

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


S>Пока что всё выглядит как попытка решить социальную проблему техническими средствами.
S>В принципе, есть несколько потенциально интересных направлений. Например, требование цифровой подписи для всех устанавливаемых приложений позволяет

... позволяет заработать на продаже водуха сертификатов.

Кроме того цифровую подпись нужно проверять и удостоверять. Мы же говорим про компьютеры обычных пользователей — значит в числе доверенных центров будут и российсие и американские и европейские УЦ. Все равно спецслужбы неизвестные злоумышленники злых вирусов подпишут и понавыпускают.

ну и не забываем про время необходимое для проверки подписей. современные ЭВМ конечно делают много операций в секунду. но как то тратятся эти операции бездарно. фактически в 2000 году программы были быстрее и отзывчивее. имхо.

Все проблемы от жадности и глупости

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Форум "философия", ... пофилосовствуем на тему — Можно ли как-то принципиально, раз и на всегда решить ворос безопасности?

AWW>Какие тут есть проблемы:
AWW>1) Вирусы
AWW>2) Трояны
AWW>3) Разграничение

Начните с гарвардской архитектуры вместо фонНеймановской. Сразу станет полегче.

O>>Да-да. Пользователи, как ни странно, удобства хотят — открывать вордом документы скачанные в браузере и таскать картинки из ворда в скайп. Причем без тыщи подтверждений и проверок, а так чтоб просто работало.
AWW>ИМХА пока до ворда далеко. Пока надо придумать архитектуру. А потом в ней уже искать "как" удобно.
Как раз таки архитектуру надо придумывать с учетом этого фактора в первую очередь, а не придумывать нечто сферическое в котором потом сверлить отверстия и вставлять в них костыли — тогда точно выйдет дырявое решето на костылях.

O>>Как раз таки архитектуру надо придумывать с учетом этого фактора в первую очередь, а не придумывать нечто сферическое в котором потом сверлить отверстия и вставлять в них костыли — тогда точно выйдет дырявое решето на костылях.
AWW>Дело в том, что когда придумывали ЭТИ ( нашу, текущую) архитектуру никто о безопасности не думал. Все думали только о том, как бы хоть как-то сделать.
Когда придумывали текущую архитектуру NT о безопасности очень даже отлично подумали. И она отлично выполняет свои задачи. Ее проблема — она слишком универсальна и изначально рассчитана на грамотных админов и программистов. В ней сущности logon session, security domain, application, process — раздельные вещи. Если объединим security domain + application + process, убрав logon sessions и запретим администраторов вообще, + к этому включим в политиках безопасности запуск только подписанных определенными вендорами исполняемых образов (включая длл) — получим по сути модель безопасности современных мобильных осей, включая ios и winrt'шные песочницы.
То есть можно административно-программно раскорячить NT так, что в неплохой мере будет удовлетворять требованиям которые вы выкатили. Но при этом она потеряет совместимость с туевой кучей софта, в определенной мере перестав быть той NT, к которой все привыкли.
И да — даже просто минимально-корректно настроенная NT фактически не подхватывает вирусов. В который раз приведу пример из жизни — моя 2я половинка, совершенно не из мира IT, пользуется лаптопом без антивиря уже 6 лет (лаптоп менялся . Ходит по контактам, форумам, фильмы смотрит с каких то сайтов. И ни разу не было обнаружено ни одного малвара. Секрет? Она сидит под юзером, если чтото требует админских прав — приходит админ (то есть я ) и решает вопрос.

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

WH>>Verve OS
KV>Что именно в Verve помешает распространяться вирусам? o_O
Как устроить эскалацию привилегий через код который не может портить память?
Добавляем сюда, что Verve является развитием Singularity, в которой безопасность построена на CBS.
И теперь расскажи, как через это пролезет вирь?

KV>...и обеспечить их взаимодействие с ОС и друг с другом. И вот тут-то и начинается самое интересное
Ничего интересного. Всё скучно и банально.
1)Системные файлы убираем с глаз долой. Они не нужны никому и никогда. Нет у пользователей задачи ковыряться в системных файлах.
2)Даём каждому приложения персональную папочку, в которой оно может делать что угодно.
3)Для того чтобы приложения могли получать доступ к файлам за приделами своей папочки достаточно сделать так чтобы приложение могло попросить оболочку показать пользователю диалог открытия файла.
То же самое касается drag&drop и copy&paste. Всё что нужно чтобы оболочка убедилась, что это делает пользователь руками. А не левый софт шалит.

Наличие такой системы безопасности обычные пользователи не заметят вообще.

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

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

A>>ну т.е. например игр на твоей платформе не будет. т.к. там внезапно скрипты и все клали болт на подписи.
A>>ты же понимаешь, что есть конкуренция между платформами, и если ты будешь мешать жить разработчикам софта, на твоей платформе не будет не только малвари, но еще и юзеров.
A>>т.е. супер-безопасная ОС это офигенно, но зачем она нужна например тем что играет в ВоВ, если там нету ВоВа?

ARK>Это вообще ортогонально вопросу безопасности. На iOS куча драконовских ограничений, а софт все равно пишут в больших количествах. На приставках тоже ограничений полно.

я думал мы говорим про десктопы.
и под играми я имел ввиду ААА игры, а не поделки типа птиц.
так вот я что-то не видел чтобы под маком было много игр типа батлфилда/планетсайда, всяких ААА мморпг и т.п.

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

A>ну т.е. например игр на твоей платформе не будет. т.к. там внезапно скрипты и все клали болт на подписи.
Странно. Вот в iOS игр — как грязи, а весь софт подписывается. Вы просто две несвязанные вещи связываете в одну.

G>>Большая часть вирей эксплуатирует ошибки в браузере и ОС (особенно драйверов и протоколов). Если ошибки устранить и действительно каждый код сможет сделать только то, что ему разрешено (CBS), то проблем не будет.
G>>Но 100% отсутствия ошибок, особенно в браузере, не удалось добиться никому.
WH>Ты вообще читал, что такое Verve?
И как verve защитит от логических ошибок ?
Серебряных пуль не бывает.

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

S>>Поэтому у меня крайне пессимистичные ожидания в этом направлении.
O>Нужно эффективное тегирование памяти. Чтоб точно трекать происхождение каждого байта, имеющегося в системе. Ведь любая имеющаяся на компе информация — она либо введена юзером, либо взята извне. Соответственно если пометить лейблой каждый байт, можно будет отследить его родословную и принять решение при выходе этой информации за пределы компа — выпускать ее или нет.
Вы прежде чем педалить — ответьте в общих чертах, каким образом это вообще поможет бороться с малварью?
Не говоря уже о том, что на каждый байт "памяти" придётся хранить мегабайт "лейблов".

S>>>Поэтому у меня крайне пессимистичные ожидания в этом направлении.
O>>Нужно эффективное тегирование памяти. Чтоб точно трекать происхождение каждого байта, имеющегося в системе. Ведь любая имеющаяся на компе информация — она либо введена юзером, либо взята извне. Соответственно если пометить лейблой каждый байт, можно будет отследить его родословную и принять решение при выходе этой информации за пределы компа — выпускать ее или нет.
S>Вы прежде чем педалить — ответьте в общих чертах, каким образом это вообще поможет бороться с малварью?
Очень просто — данные пришедшие с сайта Х не будут отправлены ни на какой сайт кроме того куда Х разрешил. Я уж не говорю какой простор для DRM — помимо источника, информацию можно помечать описанием того, что с ней вообще делать можно. В этом контексте задача по защите системных файлов решается вообще с полпинка — просто тегируем их информацию как не подлежащую изменению информацией ничьей, кроме источника microsoft.com. Любая запись в системный файл неправильного байтика — генерит суровый AV. Тоже самое с приложениями и их результатом — документами. Если документ помечен как final — любое изменение его данных ==> crash изменяющего кода. Если документ помечен как неотправляемый — send() не пройдет ибо драйвер сетевухи получит отлуп от DMA контроллера

S>Не говоря уже о том, что на каждый байт "памяти" придётся хранить мегабайт "лейблов".
Это отчасти так. Но лишь отчасти — данные в памяти таки кучкуются, и хранить лейблы лучше будет не per-byte, а per-region. Примерно так же, как сейчас организуется виртуальная память. Мегабайт тоже перебор — ассоциированное с памятью значение будет лишь уникальным идентификатором указывающим в некую базу, источников данных на самом деле не так уж много, вполне хватит, если идентификатор каждого будет дворд, то в мегабайт влезет 412144 источников. Вы уверены что у вас столько уникальных сайтов в хистори наберется?

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

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

E>Ну, то есть просто пользователь, просто няшную прогу поставить, даже на "попробовать" не сможет?

Если это левая программа (без подписи) — то, разумеется, не сможет.
Хотя можно сделать нечто вроде запуска в песочнице, без возможности записи куда-либо на диске.

E>Тогда можно прсто взять NT, юзера с провами пожиже, и для всего "лишнего" пусть зовёт админа. И безопасная ОС УЖН В КАРМАНЕ!!!

Очень смешно.
Операционная система, написанная на небезопасном языке типа С/C++, безопасной быть не может в принципе.
Кроме того, права доступа — это еще не вся безопасность, и даже не основная ее часть.

Здравствуйте, Andrew.W Worobow, Вы писали:

Чето мне вспомнился КВН

- Господа, я всё придумал! Мы купим виноград, очень много винограда! 8 тонн! И положим его в огромный целлофановый пакет! Потом закопаем всё это в землю и через месяц выкопаем! Забродивший сок увезем в Москву, где откроем свой завод. И будем этим соком заправлять выдохшиеся фломастеры! Мы станем богатыми! Очень богатыми!
— Первый канал представляет – ИДИОТЫ! По романам Федоров Михайловичей Достоевских.

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Форум "философия", ... пофилосовствуем на тему — Можно ли как-то принципиально, раз и на всегда решить ворос безопасности?

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

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>то может быть как-то можно было бы придумать, так что бы никакие вирусы и бактерии и паразиты просто не могли бы жить в таком организме.

http://www.utro.ru/articles/2011/05/23/975706.shtml

Человеческое тело, оказывается, почти целиком состоит из микроорганизмов. Однако пугаться прежде времени не стоит, пишет Daily Mail: эти существа – не чужеродные формы жизни. Для триллионов микроскопических жизненных форм человеческий организм является родным домом.
"Мы, по сути, лишь на 10% люди, а все остальное – микробы", – уверяет доктор Рой Д. Слитор из ирландского Института Корка. За четыре года основательного изучения предмета он пришел к выводу о том, что истинная роль бактериальных популяций, проживающих в человеческом организме, незаслуженно умаляется.

>кардинально
Каждому приложению своя виртуальная машина!

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

>>кардинально
O>Каждому приложению своя виртуальная машина!

Джоанна же пилит https://qubes-os.org/, это по сути оно и есть.

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Форум "философия", ... пофилосовствуем на тему — Можно ли как-то принципиально, раз и на всегда решить ворос безопасности?

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

А на практике, в 99% случаев, эти запаски не потребуются вообще, ага

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Проблема "Вирусы", это в первую очередь распостранение, можно ли как то в принципе придумать так чтобы вирусы не могли распостраняться?
Verve OS

AWW>Проблема "Трояны", это проблема скрытного выживания программы в системе, можно ли как-то придумать так чтобы скрытно сущуствовать в системе было невозможно?
Достаточно заставить все приложения устанавливаться в персональную песочницу.

Короче можно закрыть всё кроме социальной инженерии.

Здравствуйте, Stanislaw K, Вы писали:
SK>... позволяет заработать на продаже водуха сертификатов.
SK>Кроме того цифровую подпись нужно проверять и удостоверять. Мы же говорим про компьютеры обычных пользователей — значит в числе доверенных центров будут и российсие и американские и европейские УЦ. Все равно спецслужбы неизвестные злоумышленники злых вирусов подпишут и понавыпускают.
Простите, вы не могли бы поподробнее осветить этот момент с точки зрения PKI?
Каким образом эти "злоумышленники" останутся неизвестными?

SK>ну и не забываем про время необходимое для проверки подписей.
Вы серьёзно?

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

AWW>>Форум "философия", ... пофилосовствуем на тему — Можно ли как-то принципиально, раз и на всегда решить ворос безопасности?

S>Пока что всё выглядит как попытка решить социальную проблему техническими средствами.

S>В принципе, есть несколько потенциально интересных направлений. Например, требование цифровой подписи для всех устанавливаемых приложений позволяет как минимум отследить происхождение кода.

Это решение относится к решениям "типа" — забор. Ну то есть мы строим забор с калиткой, через которую пропускаем только тех кто имеет некий мандат.
Для преодоления надо подделать мандат или пройти в двоем вместе с тем кто мандат имеет.
Я же предлагаю, придумать такую систему (возможно не только ОС, пусть даже и архитектуру железа) при которой таких заборов не надо, чтобы обеспечить безопасность.
В качестве иллюстрации, продолжая образ с заборами и калитками, надо не строить заборы, а "не строить мосты". То есть что бы добратся куда то, надо построить сначала мост. Ну так как строить всегда дольше чем ломать, то при определенном условии может оказаться что мост построить будет просто "заразе" не под силу.

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

>>кардинально
O>Каждому приложению своя виртуальная машина!

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

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

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

Ну почему-же неразрешимая.
Возмите просто архитектуру где есть ЦПУ1 есть память где хранятся команды ОП1 и есть где хранятся данные ОП2. ЦПУ1 не имеет прав на запись в ОП1 и имеет все права на ОП2. Есть ЦПУ2 который имеет право на запись в ОП1 и не имеет прав на запись в ОП2.

ЦПУ2 это просто лоадер, который загржает код для большого ЦПУ1. Имеет пару команд и его код например подписан и он имеет архтектуру WLIV ( например ).

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Ну почему-же неразрешимая.

Потому что неразрешима проблема останова, к которой сводится проблема доказательства защищенности ИС

AWW>Возмите просто архитектуру где есть ЦПУ1 есть память где хранятся команды ОП1 и есть где хранятся данные ОП2. ЦПУ1 не имеет прав на запись в ОП1 и имеет все права на ОП2. Есть ЦПУ2 который имеет право на запись в ОП1 и не имеет прав на запись в ОП2.

И откуда ЦПУ2 будет брать команды для загрузки в ОП1? Вопрос риторический, сразу перескочу к главному: кто из них будет иметь право писать в порты внешних устройств, а кто считывать из них?

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Это решение относится к решениям "типа" — забор. Ну то есть мы строим забор с калиткой, через которую пропускаем только тех кто имеет некий мандат.
AWW>Для преодоления надо подделать мандат или пройти в двоем вместе с тем кто мандат имеет.
AWW>Я же предлагаю, придумать такую систему (возможно не только ОС, пусть даже и архитектуру железа) при которой таких заборов не надо, чтобы обеспечить безопасность.
AWW>В качестве иллюстрации, продолжая образ с заборами и калитками, надо не строить заборы, а "не строить мосты". То есть что бы добратся куда то, надо построить сначала мост. Ну так как строить всегда дольше чем ломать , то при определенном условии может оказаться что мост построить будет просто "заразе" не под силу.
Излишняя поэтика вредит инженерому делу. Вот, скажем, если "построить" — это найти произведение N простых множителей, а, соответственно, "сломать" — это разложить число обратно на простые множители, то ваша утверждение строго неверно.

Если вы хотите поговорить про capability-based security, то лучше так и формулировать — мы же не в детском саду.

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

AWW>>Ну почему-же неразрешимая.

KV>Потому что неразрешима проблема останова, к которой сводится проблема доказательства защищенности ИС

AWW>>Возмите просто архитектуру где есть ЦПУ1 есть память где хранятся команды ОП1 и есть где хранятся данные ОП2. ЦПУ1 не имеет прав на запись в ОП1 и имеет все права на ОП2. Есть ЦПУ2 который имеет право на запись в ОП1 и не имеет прав на запись в ОП2.

KV>И откуда ЦПУ2 будет брать команды для загрузки в ОП1? Вопрос риторический, сразу перескочу к главному: кто из них будет иметь право писать в порты внешних устройств, а кто считывать из них?

Из ПЗУ, например. Тут проблемы стартовой инициализации нет. Точнее ее лучше пока не ставить, полагая, что система как-то перешла в нужное/рабочее состояние.
Что касается внешних портов, то это простая задача, ну можно для начала считать что портов вовсе нет.

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

O>Да-да. Пользователи, как ни странно, удобства хотят — открывать вордом документы скачанные в браузере и таскать картинки из ворда в скайп. Причем без тыщи подтверждений и проверок, а так чтоб просто работало.

ИМХА пока до ворда далеко. Пока надо придумать архитектуру. А потом в ней уже искать "как" удобно.

AWW>>Форум "философия", ... пофилосовствуем на тему — Можно ли как-то принципиально, раз и на всегда решить ворос безопасности?
AWW>>Какие тут есть проблемы:
AWW>>1) Вирусы
AWW>>2) Трояны
AWW>>3) Разграничение
S>Начните с гарвардской архитектуры вместо фонНеймановской. Сразу станет полегче.
Только почемуто практические реализации гарвардской архитектуры содержат в себе потайные ходы, которые придают ей что-то неуловимо-фоннеймановское

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

S>Излишняя поэтика вредит инженерому делу. Вот, скажем, если "построить" — это найти произведение N простых множителей, а, соответственно, "сломать" — это разложить число обратно на простые множители, то ваша утверждение строго неверно.

Нет обычно в народе, принято считать, что сломать это означает, что-то удалить, или найти обходной путь.
Безопасники тем и отличаются от хакеров, что они понимают слово сломать по своему. Что-то типа я построил калитку, и три метра забора слева и справа, на кулитку поставил сторожа, все ходят и показывают ему пропуск. Сломать тут в понимании безопасника это значит подделать пропуск. Ну типа вот все же про правилам.
А сломать в понимании хакера, это значит обойти эти три метра в поле, и пройти куда надо.
То есть сломать хакера шире чем безопасника.
Вот и вы примерно исходите из этого — задаете правило для "сломать". А для сломать правило инверсное. То есть "не делать" что-то это запрешено правилами, а все остальное в рамках правил.

S>Если вы хотите поговорить про capability-based security, то лучше так и формулировать — мы же не в детском саду.

Я как раз — всю жизнь исходил из того что для того чтобы правильно пользоваться велосипедом его надо изобрести.
То есть давайте уйдем от чужих наработок. Вообще с чистого листа посмотрим на проблему.

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

O>Как раз таки архитектуру надо придумывать с учетом этого фактора в первую очередь, а не придумывать нечто сферическое в котором потом сверлить отверстия и вставлять в них костыли — тогда точно выйдет дырявое решето на костылях.

Дело в том, что когда придумывали ЭТИ ( нашу, текущую) архитектуру никто о безопасности не думал. Все думали только о том, как бы хоть как-то сделать. ИМХА сейчас уже количество перешло в качество, можно попробовать решить задачу еще раз, но уже принимая во внимание что есть проблема беопасности, да не только она кстати. Но вот сейчас хочется поговорить именно с позиции про безопасность.

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

S>>Начните с гарвардской архитектуры вместо фонНеймановской. Сразу станет полегче.
O>Только почемуто практические реализации гарвардской архитектуры содержат в себе потайные ходы, которые придают ей что-то неуловимо-фоннеймановское

Ну дык вот, сделать уже гарвардскую один раз.

Здравствуйте, Andrew.W Worobow, Вы писали:

Из довольно древнего файла о поимке льва в пустыне

///////////////////////////////////////////////////////////////

Админ.
Выкапывает вокруг клетки ров, заполняет его концентрированной кислотой,
устанавливает вдоль берега противотанковые ежи и противопехотные мины,
все это опутывает колючей проволокой. К проволоке и прутьям клетки
подключает провода от генератора высокого напряжения. Вешает на клетку
10 кодовых и 12 амбарных замков. Заходит внутрь, запирается на все
замки, пускает ток, ключи проглатывает, коды забывает и говорит, что
теперь ему никакой лев не страшен.

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

///////////////////////////////////////////////////////////////

Если серьезно...

Наверное, можно, а вот нужно ли ? Какие средства для этого понадобятся, сколько стоить будет, какие неудобства создаст ? Оправдывает ли это то увеличение безопасности, которое мы получим ?

Чаще ведь требуется не абсолютный идеал получить, а добиться оптимального с той или иной точки зрения. И зависит это от того, для какой цели ПО применяется.

Можно сделать автобусы безопасными, чтобы они людей не давили ? Можно! В 19 веке еще в Лондоне сделали. По тогдашнему закону перед каждым автобусом должен был идти человек с красным флагом, предупреждая тем самым пешеходов о той страшной опасности, которая на них надвигается. И все — автобусы людей не давили.

Правда, этот закон недолго продержался . А нынешние автобусы людей иногда давят, но только этот закон реанимировать что-то никто не предлагает.

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

AWW>>>Проблема "Вирусы", это в первую очередь распостранение, можно ли как то в принципе придумать так чтобы вирусы не могли распостраняться?
WH>>Verve OS
KV>Что именно в Verve помешает распространяться вирусам? o_O

Чую подвох, т.к. ответ на мой взгляд очевиден.

Verve здесь оверкилл.

Для разумной уверенности в "всё ок" достаточно распространения софта только через доверенные каналы с проверкой на предмет использования небезопасного API (см на WinRT). Разумеется, считаем весь системный код доверенным, целостность софта проверяется начиная с момента загрузки (см на Secure Boot). Гарантия не абсолютная, но сопоставимая с стоимостью защищаемых данных.


KV>...и обеспечить их взаимодействие с ОС и друг с другом. И вот тут-то и начинается самое интересное
Взаимодействие только через стандартные системные контракты, контракты описаны в манифесте, разрешение спрашивается при первом использовании/при установке софта.
Дальше — только социальная инженерия, но от неё силами ОС не закроешься никак.

Что упустил?

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

S>Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>>Форум "философия", ... пофилосовствуем на тему — Можно ли как-то принципиально, раз и на всегда решить ворос безопасности?

S>Пока что всё выглядит как попытка решить социальную проблему техническими средствами.
S>В принципе, есть несколько потенциально интересных направлений. Например, требование цифровой подписи для всех устанавливаемых приложений позволяет как минимум отследить происхождение кода.

вот приложение

scriptName = input()
scriptText = open(scriptName).read()
eval(scriptText)

расскажи что ты будешь тут подписывать, и как это поможет.

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

WH>>>Достаточно заставить все приложения устанавливаться в персональную песочницу.
KV>>...и обеспечить их взаимодействие с ОС и друг с другом. И вот тут-то и начинается самое интересное
O>Да-да. Пользователи, как ни странно, удобства хотят — открывать вордом документы скачанные в браузере и таскать картинки из ворда в скайп. Причем без тыщи подтверждений и проверок, а так чтоб просто работало.

Тут главное — четкий контроль, кто что может делать. Браузер может качать документы и класть их в соответствующее хранилище, а ворд может читать документы из этого хранилища. Все ОК, никаких лишних подтверждений. В современных осях в этом смысле царит полный хаос.

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

A>вот приложение
A>

A>scriptName = input()
A>scriptText = open(scriptName).read()
A>eval(scriptText)
A>

A>расскажи что ты будешь тут подписывать, и как это поможет.

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

WH>>>>Достаточно заставить все приложения устанавливаться в персональную песочницу.
KV>>>...и обеспечить их взаимодействие с ОС и друг с другом. И вот тут-то и начинается самое интересное
O>>Да-да. Пользователи, как ни странно, удобства хотят — открывать вордом документы скачанные в браузере и таскать картинки из ворда в скайп. Причем без тыщи подтверждений и проверок, а так чтоб просто работало.

ARK>Тут главное — четкий контроль, кто что может делать. Браузер может качать документы и класть их в соответствующее хранилище, а ворд может читать документы из этого хранилища. Все ОК, никаких лишних подтверждений. В современных осях в этом смысле царит полный хаос.
А если я захочу браузером отправить документ?

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

A>>расскажи что ты будешь тут подписывать, и как это поможет.

ARK>В данном случае мы вправе ожидать, что произвольный скрипт может выполнить любые действия, доступные интерпретатору.

Вообще-то скрипты подписываются уже давно-давно, причем они шифруются еще при этом, ну типа проверяется ЭЦП, затем расшифровывается закрытым ключом если ЭЦП верна.
Выглядят они внутри как бинарники, можно хранить в виде текстовых base64. Тут как раз проблем нет.
Проблемы в том, что надо иметь такую систему, где можно было бы выполнять любой код, и это бы ни приводило к нарушению системы. То есть не нужно ни ЭЦП ни рутовские права.

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

ARK>>Тут главное — четкий контроль, кто что может делать. Браузер может качать документы и класть их в соответствующее хранилище, а ворд может читать документы из этого хранилища. Все ОК, никаких лишних подтверждений. В современных осях в этом смысле царит полный хаос.
O>А если я захочу браузером отправить документ?

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

Здравствуйте, Andrew.W Worobow, Вы писали:

ARK>>В данном случае мы вправе ожидать, что произвольный скрипт может выполнить любые действия, доступные интерпретатору.
AWW>Вообще-то скрипты подписываются уже давно-давно

Вообще-то слово "input" намекает на произвольное происхождение скрипта, например ввод его с клавиатуры.

AWW>Проблемы в том, что надо иметь такую систему, где можно было бы выполнять любой код, и это бы ни приводило к нарушению системы. То есть не нужно ни ЭЦП ни рутовские права.

Что понимается под "нарушением системы" и как отличить нарушение от желаемого действия? Удаление документа — это нарушение системы?

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

ARK>Вообще-то слово "input" намекает на произвольное происхождение скрипта, например ввод его с клавиатуры.

Ну и скрипт при этом должен быть подписан.

AWW>>Проблемы в том, что надо иметь такую систему, где можно было бы выполнять любой код, и это бы ни приводило к нарушению системы. То есть не нужно ни ЭЦП ни рутовские права.

ARK>Что понимается под "нарушением системы" и как отличить нарушение от желаемого действия? Удаление документа — это нарушение системы?

Нарушение это не контролируемое, не регламентированное действие. То есть если по регламенту можно удалить документ, то это не нарушение.
А вот если при наличии "запрета" удалять, допумент все же можно ( как-то, внедрив код, взломав ядро и пр ) удалить, то это нарушение системы.

WH>>>Verve OS
KV>>Что именно в Verve помешает распространяться вирусам? o_O
WH>Как устроить эскалацию привилегий через код который не может портить память?
WH>Добавляем сюда, что Verve является развитием Singularity, в которой безопасность построена на CBS.
WH>И теперь расскажи, как через это пролезет вирь?
KV>>...и обеспечить их взаимодействие с ОС и друг с другом. И вот тут-то и начинается самое интересное
WH>Ничего интересного. Всё скучно и банально.
WH>1)Системные файлы убираем с глаз долой. Они не нужны никому и никогда. Нет у пользователей задачи ковыряться в системных файлах.
WH>2)Даём каждому приложения персональную папочку, в которой оно может делать что угодно.
WH>3)Для того чтобы приложения могли получать доступ к файлам за приделами своей папочки достаточно сделать так чтобы приложение могло попросить оболочку показать пользователю диалог открытия файла.
WH>То же самое касается drag&drop и copy&paste. Всё что нужно чтобы оболочка убедилась, что это делает пользователь руками. А не левый софт шалит.
WH>Наличие такой системы безопасности обычные пользователи не заметят вообще.

Ну еще чуть-чуть и окончательно изобретем ios

ARK>>>Тут главное — четкий контроль, кто что может делать. Браузер может качать документы и класть их в соответствующее хранилище, а ворд может читать документы из этого хранилища. Все ОК, никаких лишних подтверждений. В современных осях в этом смысле царит полный хаос.
O>>А если я захочу браузером отправить документ?
ARK>Я думаю, что отправка через браузер различных типов файлов — вполне ожидаемое действие, и соответствующее разрешение по умолчанию будет. А вот если инсталлятор программы VasyaPupkendMegaApp захочет слелать то же самое, или захочет записать некий файлик в репозиторий драйверов, то ему в этом будет отказано.
Ну то есть поделим приложения на кошерные и остальные. Вопрос — кто будет раввином, определяющим кошерность (и чья печать будет стоять в окошке при инсталляции приложения)?

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Форум "философия", ... пофилосовствуем на тему — Можно ли как-то принципиально, раз и на всегда решить ворос безопасности?

Можно, unix называется. Пароноидально настроенный unix пуленепробиваем. Был в школе опыт когда 500 отморозков со средним IQ > 120 полгода ломали параноидально настроенную NT и параноидально настроенную FreeBSD. NT сломали, а фряха устояла.

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

O>Каждому приложению своя виртуальная машина!
Поздравляю, вы изобрели один из компонентов безопасности Xbox One.

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

P>Можно, unix называется. Пароноидально настроенный unix пуленепробиваем. Был в школе опыт когда 500 отморозков со средним IQ > 120 полгода ломали параноидально настроенную NT и параноидально настроенную FreeBSD. NT сломали, а фряха устояла.
Не сработает. Никакая система пассивной безопасности (т.е. та, в которой нет активно действующей "контрразведки") не устоит против человеческого фактора.
То есть, грубо говоря, можно попробовать закрыть на зиму дачный домик ставнями. Сломают. Железными ставнями — вскроют автогеном. Накрыть железобетонным колпаком — взорвут.
А можно на 1/1000 стоимости железобетонного купола посадить дедушку с берданкой и свистком — и он будет эффективно отгонять любых отморозков. Благодаря гибкой стратегии защиты — т.е. он будет подбирать противодействия против любой стратегии взлома, а при превышении мощности будет вызывать помощь.

Так и в IT — если дать отморозкам неограниченное время, то они сломают любую систему. Пароли — забрутфорсят, социалку — заинженерят. Заразят админу загрузочную флешку, и при штатном обслуживании сервака пропишут руткит прямо в бутсектор

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>"придумать" как эти машины или среды будут жить уже на уровне процессоров
Hardware-assisted hypervisor.

AWW>И почему никак будет не возможно выйти из этой машины в другую или в супервизор
Баги в гипервизорах на практике встречаются, и иногда приводят к побегу из песочницы.
Однако hardware-assisted hypervisor это весьма небольшое количество строк кода, т.е. у него очень маленький attack surface.
Поэтому если у вас есть инструменты обновления кода гипервизора, и он устойчив к подмене, то безопасность OK.
Смотрите Xbox 360, который на рынке уже 9 лет, а под него не то что вирусов нет, даже нет годного способа его взломать, шоб он исполнял сторонние или модифицированные приложения.

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

S>Но в целом сочетание идей CAS и CBS позволяют защищать и такие вещи.
CAS не нужен. CBS необходим и достаточен.

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

O>Ну то есть поделим приложения на кошерные и остальные. Вопрос — кто будет раввином, определяющим кошерность (и чья печать будет стоять в окошке при инсталляции приложения)?

Нет, ничего делить не будем. В системе будет некоторый набор прав — доступ в интернет, чтение из указанного хранилища (хранилище текстовых документов, аудиофайлов, видеофайлов, изображений, файлов автокада и т.п.), запись в указанное хранилище, создание дочерних процессов, установка приложений и т.д. Также будет несколько стандартных групп прав — "браузер", "просмотрщик картинок", "текстовый редактор", "среда разработки", etc. Каждое конкретное приложение при инсталляции должно будет отнести себя к некоторой группе и/или потребовать отдельный/дополнительный набор прав. Приложения, подписанные сертификатом, можно установить без предупреждений. Неподписанные должны явно получить одобрение администратора. Примерно так.

O>>Ну то есть поделим приложения на кошерные и остальные. Вопрос — кто будет раввином, определяющим кошерность (и чья печать будет стоять в окошке при инсталляции приложения)?
ARK>Нет, ничего делить не будем. В системе будет некоторый набор прав — доступ в интернет, чтение из указанного хранилища (хранилище текстовых документов, аудиофайлов, видеофайлов, изображений, файлов автокада и т.п.), запись в указанное хранилище, создание дочерних процессов, установка приложений и т.д. Также будет несколько стандартных групп прав — "браузер", "просмотрщик картинок", "текстовый редактор", "среда разработки", etc. Каждое конкретное приложение при инсталляции должно будет отнести себя к некоторой группе и/или потребовать отдельный/дополнительный набор прав. Приложения, подписанные сертификатом, можно установить без предупреждений. Неподписанные должны явно получить одобрение администратора. Примерно так.
Идея не нова. Но во первых — тогда все приложения начнут требовать все права, а все юзеро-админы их будут акцептит, как это и происходит сейчас под ведроидом . Во вторых — формальное разделение породит просто огромное количество групп. Фактически равное количеству программ в системе среднего юзера (кто кроме гиков ставит себе 10 просмотрщиков картинок?). То есть при установке каждой программы помимо самой программы юзер увидит в окне подверждения еще одно слово, которое будет просто довеском к названию программы, не обобщая имеющиеся у него программы.

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

S>Здравствуйте, Abyx, Вы писали:
A>>вот приложение
A>>

A>>scriptName = input()
A>>scriptText = open(scriptName).read()
A>>eval(scriptText)
A>>

A>>расскажи что ты будешь тут подписывать, и как это поможет.
S>приложение буду подписывать. Если потом окажется, что оно исполняет злонамеренные скрипты, то мы отзовём сертификат автора, а автора показательно покараем анально.
S>В следующий раз он не будет скармливать текст из неизвестного источника в функцию eval().

ну т.е. например игр на твоей платформе не будет. т.к. там внезапно скрипты и все клали болт на подписи.
ты же понимаешь, что есть конкуренция между платформами, и если ты будешь мешать жить разработчикам софта, на твоей платформе не будет не только малвари, но еще и юзеров.
т.е. супер-безопасная ОС это офигенно, но зачем она нужна например тем что играет в ВоВ, если там нету ВоВа?

ну и я так понял интерпретатора питона на твоей ОС тоже не будет? как и например компиляторов типа csc.exe

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

O>Идея не нова. Но во первых — тогда все приложения начнут требовать все права, а все юзеро-админы их будут акцептит, как это и происходит сейчас под ведроидом .

Да, это возможно. Но это уже другой вопрос. По крайней мере при желании можно четко видеть, кто что использует, и можно управлять этим процессом (во время инсталляции и после нее).

O>Во вторых — формальное разделение породит просто огромное количество групп. Фактически равное количеству программ в системе среднего юзера (кто кроме гиков ставит себе 10 просмотрщиков картинок?).

Нет, много групп не будет — типов приложений не так уж много.
Наличие группы "просмотрщик картинок" не означает, что юзер должен ставить их 10 штук (более того, у юзера их может вообще не быть ни одного). Эта и другие стандартные группы дают понять юзеру, что существует такой вот класс приложений, и что он для работы требует такие вот права.

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

A>ну т.е. например игр на твоей платформе не будет. т.к. там внезапно скрипты и все клали болт на подписи.
A>ты же понимаешь, что есть конкуренция между платформами, и если ты будешь мешать жить разработчикам софта, на твоей платформе не будет не только малвари, но еще и юзеров.
A>т.е. супер-безопасная ОС это офигенно, но зачем она нужна например тем что играет в ВоВ, если там нету ВоВа?

Это вообще ортогонально вопросу безопасности. На iOS куча драконовских ограничений, а софт все равно пишут в больших количествах. На приставках тоже ограничений полно. В общем, если платформа будет прибыльной, то разработчики быстренько уберут свои болты в штаны и будут делать что положено (в том числе и подписи использовать).

O>>Идея не нова. Но во первых — тогда все приложения начнут требовать все права, а все юзеро-админы их будут акцептит, как это и происходит сейчас под ведроидом .
ARK>Да, это возможно. Но это уже другой вопрос. По крайней мере при желании можно четко видеть, кто что использует, и можно управлять этим процессом (во время инсталляции и после нее).

O>>Во вторых — формальное разделение породит просто огромное количество групп. Фактически равное количеству программ в системе среднего юзера (кто кроме гиков ставит себе 10 просмотрщиков картинок?).
ARK>Нет, много групп не будет — типов приложений не так уж много.
ARK>Наличие группы "просмотрщик картинок" не означает, что юзер должен ставить их 10 штук (более того, у юзера их может вообще не быть ни одного). Эта и другие стандартные группы дают понять юзеру, что существует такой вот класс приложений, и что он для работы требует такие вот права.
просмотрщик картинок, просмотрщик офисодокументов, просмотрщик автокадов, редактор картинок, редактор офисодокументов, редактор автокадов, прослушивальщик аудио, просматривальщик видео, ... нет я не имею ввиду что сама идея бессмысленная, просто разграничение на группы очень шатко. С крупнной гранулярностью в пределах группы мы имеем ту же самую дырявость как и в пределах logon session сейчас в винде. А если сделать гранулярность делать совсем мелкий — получим что количество групп программ в системе будет примерно равно количеству программ.

Ну и это, даже для винды это уже велосипед. RTшный, само собой.

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Форум "философия", ... пофилосовствуем на тему — Можно ли как-то принципиально, раз и на всегда решить ворос безопасности?

AWW>Какие тут есть проблемы:
AWW>1) Вирусы

...

А почему нет? Что нам надо от программы? Чтобы по входным данными посчитала выходные. Для этого совсем не обязателдьно давать ей право записывать свою копию в коды других программ, как это делают вирусы — достаточно вызывать с ее параметрами — ссылки на входные данные (только чтение) и ссылка на пустую память для выходных данных. Только для этого требуется посидеть подумать, чтобы такая система ссылок годилась для любых программ, а вот этим народ заниматься не любит. Проще дать право программе читать-писать любые файлы и надеяться, что пронесет.

Здравствуйте, Abyx, Вы писали:
A>и под играми я имел ввиду ААА игры, а не поделки типа птиц.
Это вы наверное про XBOX и PS?
Там всегда есть AAA

rfq>А почему нет? Что нам надо от программы? Чтобы по входным данными посчитала выходные. Для этого совсем не обязателдьно давать ей право записывать свою копию в коды других программ, как это делают вирусы — достаточно вызывать с ее параметрами — ссылки на входные данные (только чтение) и ссылка на пустую память для выходных данных. Только для этого требуется посидеть подумать, чтобы такая система ссылок годилась для любых программ, а вот этим народ заниматься не любит. Проще дать право программе читать-писать любые файлы и надеяться, что пронесет.
Файлы это и есть память для входных и выходных данных.
Более того — все современные оси позволяют разграничивать права доступа на файлы. Просто никто этим не парится, потому что полное разграничение всего и вся порождает кучу геморроя с которым ни юзеры ни программеры не смирятся.

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

WH>Здравствуйте, kochetkov.vladimir, Вы писали:

WH>>>Verve OS
KV>>Что именно в Verve помешает распространяться вирусам? o_O
WH>Как устроить эскалацию привилегий через код который не может портить память?
WH>Добавляем сюда, что Verve является развитием Singularity, в которой безопасность построена на CBS.
WH>И теперь расскажи, как через это пролезет вирь?

Большая часть вирей эксплуатирует ошибки в браузере и ОС (особенно драйверов и протоколов). Если ошибки устранить и действительно каждый код сможет сделать только то, что ему разрешено (CBS), то проблем не будет.
Но 100% отсутствия ошибок, особенно в браузере, не удалось добиться никому.

Но есть еще социальная инженерия, типа "мои фотки с моря.jpg.exe", оно решается установкой только из доверенного источника с цифровой подписью. Но на практике не решается. Ибо есть закрытые сети, где доступ к надежному источнику блокирован и нет возможности проверить подпись, а также sideloading нужен для разработчиков. Так вот сайдлоадинг также подвержен ошибкам, которые злоумышленники обязательно будут эксплуатировать.

То есть вирус не сможет пролезть в систему без ошибок в теории. А на практике — будут ошибки и будут вирусы.

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

G>Большая часть вирей эксплуатирует ошибки в браузере и ОС (особенно драйверов и протоколов). Если ошибки устранить и действительно каждый код сможет сделать только то, что ему разрешено (CBS), то проблем не будет.
G>Но 100% отсутствия ошибок, особенно в браузере, не удалось добиться никому.
Ты вообще читал, что такое Verve?

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

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

G>>Большая часть вирей эксплуатирует ошибки в браузере и ОС (особенно драйверов и протоколов). Если ошибки устранить и действительно каждый код сможет сделать только то, что ему разрешено (CBS), то проблем не будет.
G>>Но 100% отсутствия ошибок, особенно в браузере, не удалось добиться никому.
WH>Ты вообще читал, что такое Verve?
Вообще читал. Но в 100% отсутствие ошибок не верю все равно.

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

O>Идея не нова. Но во первых — тогда все приложения начнут требовать все права, а все юзеро-админы их будут акцептит, как это и происходит сейчас под ведроидом .

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

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Из ПЗУ, например.

А каким образом они будут туда попадать?

AWW>Что касается внешних портов, то это простая задача, ну можно для начала считать что портов вовсе нет.

Это нерешаемая задача Ну, а если нет портов, то такой сферический компьютер в вакууме будет мало кому интересен.

Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, kochetkov.vladimir, Вы писали:

WH>>>Verve OS
KV>>Что именно в Verve помешает распространяться вирусам? o_O
WH>Как устроить эскалацию привилегий через код который не может портить память?

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

WH>3)Для того чтобы приложения могли получать доступ к файлам за приделами своей папочки достаточно сделать так чтобы приложение могло попросить оболочку показать пользователю диалог открытия файла.
WH>То же самое касается drag&drop и copy&paste. Всё что нужно чтобы оболочка убедилась, что это делает пользователь руками. А не левый софт шалит.

А кто будет следить за тем, что данные пришедшие по сети не были подменены человеком посередине? Как быть с приложениями, поддерживающими плагины или функциональность которых требует обмена инфой с соседними без участия пользователя?

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

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

G>>Большая часть вирей эксплуатирует ошибки в браузере и ОС (особенно драйверов и протоколов). Если ошибки устранить и действительно каждый код сможет сделать только то, что ему разрешено (CBS), то проблем не будет.
G>>Но 100% отсутствия ошибок, особенно в браузере, не удалось добиться никому.
WH>Ты вообще читал, что такое Verve?

От XSS она не защитит ("немного" не тот уровень абстракции), а следовательно, атакующий уже может выполнить в контексте сайта/браузера/пользователя произвольный код. Для кражи данных онлайн-банкинга этого более чем достаточно.

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

O>И как verve защитит от логических ошибок ?
O>Серебряных пуль не бывает.

Никак. Именно это и доказывается в тех работах, о которых я упоминал в самом начале.

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

S>достаточно распространения софта только через доверенные каналы

...и данных, которые этот софт обрабатывает тоже. На этом сосбственно, идея абсолютно защищенного софта и заканчивается.

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

S>>достаточно распространения софта только через доверенные каналы
KV>...и данных, которые этот софт обрабатывает тоже. На этом сосбственно, идея абсолютно защищенного софта и заканчивается.

Угу, с этим никто не спорит вроде.
Только топик не про защищённость софта, а про безопасность ОС. Конкретно эта ветка — вообще про "усложнить жизнь вирусам". Песочница позволяет свести проблему до уровня "выполняем произвольный код в песочнице", что в принципе ничем не опаснее обычного вебсайта.

S>Поэтому у меня крайне пессимистичные ожидания в этом направлении.
Нужно эффективное тегирование памяти. Чтоб точно трекать происхождение каждого байта, имеющегося в системе. Ведь любая имеющаяся на компе информация — она либо введена юзером, либо взята извне. Соответственно если пометить лейблой каждый байт, можно будет отследить его родословную и принять решение при выходе этой информации за пределы компа — выпускать ее или нет.
Я както пытался сделать такой софтово — капец педалево вышло. Нужно чтобы архитектура (аппаратная или виртуальная машина) это эффективно поддерживала, скажем чтоб такая фигня работала быстро и автоматически выводила лейблы на памяти по типу:
входные условия

лейблы на входе:
edi - указывает на контент, скачанный с google.com
esi - указывает на контент, введенный юзером

mov eax, [edi] ;
mov ebx, [esi]
add eax, ebx
mov [edi], eax 

лейблы на выходе:
edi - указывает на контент, скачанный с google.com и подредактированный юзером
esi - указывает на контент, введенный юзером

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

O>И как verve защитит от логических ошибок ?
O>Серебряных пуль не бывает.
Всё что я вижу это то, что авторы не написали ни одного теста для кода, который по-хорошему должен быть доказан.

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

KV>От XSS она не защитит ("немного" не тот уровень абстракции), а следовательно, атакующий уже может выполнить в контексте сайта/браузера/пользователя произвольный код. Для кражи данных онлайн-банкинга этого более чем достаточно.
Просто банки должны использовать что-то типа:
http://www.impredicative.com/ur/

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

KV>Порча памяти здесь не причем. .NET-приложение, подверженное атакам, связанным с порчей памяти еще поискать надо. Но это не делает .NET приложения неуязвимыми, т.к. атаки на подобные уязвимости составляют около трети от числа всех ныне известных
А можно список других уязвимостей?

KV>А кто будет следить за тем, что данные пришедшие по сети не были подменены человеком посередине?
Алгоритм, который устанавливает защищённое от человека посередине соединение.
Уверен, ты знаешь несколько.

KV>Как быть с приложениями, поддерживающими плагины
1)Плагин при всём желании не сможет сделать больше, чем позволено приложению.
2)CBS легко позволяет посадить плагин в жестокую песочницу. Для этого просто достаточно дать плагину только то, что ему нужно. Остальное он никогда не получит.

KV>или функциональность которых требует обмена инфой с соседними без участия пользователя?
А можно пример?

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

AWW>>Из ПЗУ, например.

KV>А каким образом они будут туда попадать?

Ну самый простой ответ — либо на заводе, либо тот самый второй ЦПУ который только это и умеет будет туда записывать.

AWW>>Что касается внешних портов, то это простая задача, ну можно для начала считать что портов вовсе нет.

KV>Это нерешаемая задача Ну, а если нет портов, то такой сферический компьютер в вакууме будет мало кому интересен.

Да почему же — например отображение в память.

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

S>>>>Поэтому у меня крайне пессимистичные ожидания в этом направлении.
O>>>Нужно эффективное тегирование памяти. Чтоб точно трекать происхождение каждого байта, имеющегося в системе. Ведь любая имеющаяся на компе информация — она либо введена юзером, либо взята извне. Соответственно если пометить лейблой каждый байт, можно будет отследить его родословную и принять решение при выходе этой информации за пределы компа — выпускать ее или нет.
S>>Вы прежде чем педалить — ответьте в общих чертах, каким образом это вообще поможет бороться с малварью?
O>Очень просто — данные пришедшие с сайта Х не будут отправлены ни на какой сайт кроме того куда Х разрешил.
Хм. Ну вот, например, у меня сайт X — это фотошоп онлайн. Я правильно понимаю, что картинки, наредактированные этим сайтом, нельзя девать никуда, кроме жёстко прошитого списка сайтов?
Т.е. на facebook.com можно, а на facebook.ru — уже нельзя?
S>>В этом контексте задача по защите системных файлов решается вообще с полпинка — просто тегируем их информацию как не подлежащую изменению информацией ничьей, кроме источника microsoft.com.
O>Это отчасти так. Но лишь отчасти — данные в памяти таки кучкуются, и хранить лейблы лучше будет не per-byte, а per-region. Примерно так же, как сейчас организуется виртуальная память. Мегабайт тоже перебор — ассоциированное с памятью значение будет лишь уникальным идентификатором указывающим в некую базу, источников данных на самом деле не так уж много, вполне хватит, если идентификатор каждого будет дворд, то в мегабайт влезет 412144 источников. Вы уверены что у вас столько уникальных сайтов в хистори наберется?
А у кого будут права на запись в базу идентификаторов?

Здравствуйте, ononim, Вы писали:
O>Ну вот зачем сразу утрировать и пытаться свести к абсурдности? В стандартном DACL вы тоже перечисляете всех и каждого или там еще группы есть?
Стандартный DACL, как мы знаем, от малвари защищает чуть меньше, чем никак.
Поэтому я и пытаюсь понять, что именно делается.

S>>А у кого будут права на запись в базу идентификаторов?
O>У ядра оси, разумеется. Тут — полная аналогия с системой виртуальной памяти.
O>Заранее сразу отвечаю на пару вопросов:
O>1) Ядро оси никто не сможет модифицировать, окромя тех кому можно (а можно — информации, созданной производителем оси).
O>2) ДА. Это получится очень анально огороженная архитектура.

O>3) _Можно_ развить концепцию до еще более анально огороженной trusted hardware platform:
O>3.а) Писать в базу идентификаторов сможет только железо (зашитая в нем фирмварь)
O>3.б) Сетевые адаптеры должны аппаратно поддерживать SSL. Любая входящая по сети информация должна автоматически тегироваться группами, прописанными в сертификате другой стороны. Если не SSL — значит группа anonymous.
O>3.в) У пользователя системы должен быть личный сертификат, с помощью которого клава/мышь/тач так же будут тегировать весь его ввод, с возможностью криптографической его верификации в случае необходимости (банковская транзакция, заказ авиабилета, пост в КЫВТ...)
Это всё малоинтересные подробности.
Давайте поймём простую вещь: вот у меня есть, допустим, авиабилет, купленный на сайте аэрофлота. У меня, допустим, есть приложение А — "календарь", с разрешением синхронизоваться с моим смартфоном. Для упрощения предположим, что это — веб приложение, т.е. просто другой сайт. Есть сценарий "добавить данные авиабилета в календарь". Естественно, мы предполагаем, что само приложение календаря было разработано независимым вендором через пять лет после того, как сайт аэрофлота был запущен.
Что должен сделать и кто чтобы разрешить пользователю выполнить этот сценарий?

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. А может и нет — ну, никтож не обещал утопию.

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

O>Он отлично защищает от малвари от которой задуман защищать,
Пока что этого не видно.
O>а вы все так же банальным утрированием пытаетесь все свести к абсурду.
Я пытаюсь проверить граничные случаи. А вы похоже вообще ни один из реальных сценариев не продумали от начала и до конца.

O>Создатель приложения должен будет квалифицировать возможность применения информации, сгенеренной его приложением. Опять же опустимся к DACL'ам. В юниксах любят троицу owner/group/world. У нас в принципе выделяется троица домен создателя информации, домен пользователя которому она придет, и — все остальные.
А что, у всех пользователей есть свои домены? У меня, к примеру, нету.

O>Соответственно в первом приближении если создатель приложения разрешил 'миру' читать его информацию — ты сможешь ее передать куда угодно. Если нет — никуда не передашь.
В этом приближении задача неразрешима. Потому что "куда угодно" — это, в частности, злоумышленнику, который сдаёт билет и получает деньги. (В более реалистичном случае, возможном прямо сейчас, он сдаёт билет не для денег, а чтобы освободить место на нужный ему рейс).
А "никуда не передашь" означает принципиальную невозможность добавить вылет в расписание.

O>Во втором приближении появляются группы, и создатель может выдать разрешение определенным группам, в которые возможно и попадет сайт аэрофлота в будущем, если он того пожелает и если это заапрувит certificate authrity. А может и нет — ну, никтож не обещал утопию.
Это не утопия, это минимально необходимый уровень сервиса. Получается, что у вас всё построено на группах.
Значит, надо их архитектуру проработать как-то более тщательно. Ну и оценить всё же накладные расходы.

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

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

Просто интересно: а отрендеренный на экране суперсекретный текст будет приводить к невозможности создать и куда-нибудь отправить скриншот? Считать инфу попискельно из параллельного процесса? А если морзой пропищать защищенный таким образом регион памяти, другой процесс сможет его прослушать через микрофон и отправить злохакерам?

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

WH>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Порча памяти здесь не причем. .NET-приложение, подверженное атакам, связанным с порчей памяти еще поискать надо. Но это не делает .NET приложения неуязвимыми, т.к. атаки на подобные уязвимости составляют около трети от числа всех ныне известных
WH>А можно список других уязвимостей?

Веб+хит парады: http://projects.webappsec.org/w/page/13246975/Threat%20Classification%20Taxonomy%20Cross%20Reference%20View
Более подробная классификация: http://cwe.mitre.org/data/published/cwe_v2.8.pdf

KV>>А кто будет следить за тем, что данные пришедшие по сети не были подменены человеком посередине?
WH>Алгоритм, который устанавливает защищённое от человека посередине соединение.
WH>Уверен, ты знаешь несколько.

Не знаю ни одного, эффективно реализуемого без необходимости необоснованно доверять третьей стороне

KV>>Как быть с приложениями, поддерживающими плагины
WH>1)Плагин при всём желании не сможет сделать больше, чем позволено приложению.

В современных реалиях большего и не нужно. Хотя за рамки угроз уровня ОС это конечно выходит.

O>>Нужно эффективное тегирование памяти. Чтоб точно трекать происхождение каждого байта, имеющегося в системе. Ведь любая имеющаяся на компе информация — она либо введена юзером, либо взята извне. Соответственно если пометить лейблой каждый байт, можно будет отследить его родословную и принять решение при выходе этой информации за пределы компа — выпускать ее или нет.
KV>Просто интересно: аа отрендеренный на экране суперсекретный текст будет приводить к невозможности создать и куда-нибудь отправить скриншот? Считать инфу попискельно из параллельного процесса?
Пиксели — это не более чем ячейки (видео) памяти, которые разумеется тоже должны быть меченые.

KV>А если морзой пропищать защищенный таким образом регион памяти, другой процесс сможет его прослушать через микрофон и отправить злохакерам?
Интересный вопрос. Както я про такой сценарий не задумывался, но вообще ответ в голову пришел: если на динамики отправляется какая либо информация и при этом с микрофона идет запись — вполне логично считать входящую информацию с микрофона облагаемой теми же пермишенами, как и проигрываемая в тот же момент. Кроме того информацию можно явне тегировать как не подлежащую отправку в аудиоустройства (а точнее — явно тегировать только то, что можно проигрывать) и такая проблема вообще не возникнет.

И еще сразу отвечу на висящий в воздухе вопрос, по поводу секретных данных, которые могут быть перепечатаны/прочитаны/насвистаны/записаны на магнитофон самим юзером. Против _юзеров_, которые специально тырят секретные данные которые сами могут просматривать на горизонте решений не просматривается (вживление микрочипов в мозг — это пока еще за горизонтом ). Натайпанные юзером данные автоматом будут считать произведенными юзером и иметь соответствующие разрешения. Но вот касательно этих разрешений есть ньюанс:
1) Если юзер задасться целью слить свои данные злоумышленникам — он это всегда сможет сделать. В плане защиты от утечек информации эта штука будет работать только при сотрудничестве со стороны юзера. От промышленного шпионажа это решение — лишь очередной слой obscurity.
2) Если же юзер сам заинтересован чтобы сохранить эти данные в секрете, но при этом мы боимся что его обманным путем (вплоть до гипноза) их заставят натайпать, то несложно будет сделать классификацию вводимой информации, наподобии тех что ставятся в корпоративных периметрах и сканят например почту на предмет случайного сообщения потенциально секретных данных потенциальному злодею. Основная проблема таких существующих решений — что секретная информация на периметре может быть в совершенно любом виде, поэтому даже самый допропорядочный юзер может случайно слить ее, например переслав каким нить малоизвестным месенжером, не говоря уж о малварном софте, который может просто все зашифровать способом известным лишь его автору и отправить под видом DNS запросов. А вот информация поступающая с HID'ов — она всегда в известном формате, и анализировать для автоматической классификации ее там будет намного проще — вплоть до околонулевого участия юзера в этом деле. Ну а после классификации ее уже никак не стырить будет.

O>>Он отлично защищает от малвари от которой задуман защищать,
S>Пока что этого не видно.
O>>а вы все так же банальным утрированием пытаетесь все свести к абсурду.
S>Я пытаюсь проверить граничные случаи.
До сих пор вы задавали вопросы с очевидными ответами, тем не менее делая вид что не видите этих ответов. Ну или правда совершенно не задумывались и потому их не видели.

S>А вы похоже вообще ни один из реальных сценариев не продумали от начала и до конца.
Вообще эта идея мне пришла в ходе ресерча на тему как улучшить один наш rights managment продукт. Когда я рассказал менеджменту идею и показал тормозящий Блокнот, сказав что если вложить дофига усилий можно получить офигенную конфетку, но к сожалению не могу пока предсказать из какой она будет субстанции — менеджмент почесал бошку и сказал ну его нафиг, давайте лучше дальше наши кривохаки пилить. А о том что такая модель безопасности вобщемто тянет на замену устоявшимся юникс пермишенам и даклам я вообще тогда промолчал, дабы совсем у виска не покрутили. А сейчас вот прочитав эту ветку — вспомнилось. Так что не надо ожидать что я прямо вот ща вам вывалю whitepaper на тыщу страниц и печатью ОТК за подписью Брюса Шнайера и ведущих специалистов по юзабилити.
Просто текущие системы безопасности NT/Unix тащат свои корни с лохматых времен с мэйнфреймами, на которых сидели различные пользователи, и каждый пользователь делал какую нибудь одну, но очень важную для него вещь. В таком окружении та модель замечательно работает: там пользователь == защищаемые данные. Проблема в том что сейчас ее пытаются натянуть на однопользовательское окружение, в котором куча разных данных, совершенно различными "степенями секретности", но все они варятся в едином котле одного уровня привилегий. А разделить уровни — непонятно как, потому что просто нет прямого и естественного пути их перегруппировать, причем так чтоб потом еще и можно было шарить друг с другом. Опять же старая модель безопасности предполагала наличие админа, который бы всем настроил пермишены и сказал кому что можно, а кому что нельзя. В нынешней же солянке информации на типичной системе никакой админ не разберется, кроме того она постоянно меняется. Для защиты данных нужна новая модель безопасности, которая защищает именно данные, а не какието произвольные сущности которые с конкретными данными однозначно и на словах увязать то сложно, а не то что формально описать и запрограммировать.

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

...
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

. И таких сценариев когда сервисы и программы водят хороводы и гоняют данные из сети туда-сюда не так мало. Надеюсь если этот "мега-дрм" начнет материализовываться юзерам не придется рвать волосы разработчиков =)

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

KV>>А если морзой пропищать защищенный таким образом регион памяти, другой процесс сможет его прослушать через микрофон и отправить злохакерам?
O>Интересный вопрос. Както я про такой сценарий не задумывался, но вообще ответ в голову пришел: если на динамики отправляется какая либо информация и при этом с микрофона идет запись — вполне логично считать входящую информацию с микрофона облагаемой теми же пермишенами, как и проигрываемая в тот же момент. Кроме того информацию можно явне тегировать как не подлежащую отправку в аудиоустройства (а точнее — явно тегировать только то, что можно проигрывать) и такая проблема вообще не возникнет.

Не, такие вещи отследить вряд ли возможно. У Эндрю Таненбаума в книге "Операционные системы. Разработка и реализация" где-то был пример скрытной передачи информации путем отслеживания нагрузки процессора — если активность в течение какого-то времени выше определенного порога, то это 1, если ниже — то 0.

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

Здравствуйте, ononim, Вы писали:
O>До сих пор вы задавали вопросы с очевидными ответами, тем не менее делая вид что не видите этих ответов.
Пока что вы ни на один из них толком не ответили. Как я и полагал, у вас хорошо продуман нижний уровень, но нет ни малейшего представления о том, как из этого нижнего уровня собрать решение для пользовательских сценариев. Я сам таким изобретательством занимался в 19 лет

O>Вообще эта идея мне пришла в ходе ресерча на тему как улучшить один наш rights managment продукт. Когда я рассказал менеджменту идею и показал тормозящий Блокнот, сказав что если вложить дофига усилий можно получить офигенную конфетку, но к сожалению не могу пока предсказать из какой она будет субстанции — менеджмент почесал бошку и сказал ну его нафиг, давайте лучше дальше наши кривохаки пилить. А о том что такая модель безопасности вобщемто тянет на замену устоявшимся юникс пермишенам и даклам я вообще тогда промолчал, дабы совсем у виска не покрутили. А сейчас вот прочитав эту ветку — вспомнилось. Так что не надо ожидать что я прямо вот ща вам вывалю whitepaper на тыщу страниц и печатью ОТК за подписью Брюса Шнайера и ведущих специалистов по юзабилити.
Нет, зачем 1000 страниц. Достаточно внятно изложить идею — не просто "давайте пометим каждый байт", а на пальцах. Вот, скажем, идею PKI можно изложить в пяти абзацах так, чтобы стало понятно, каким образом решаются проблемы безопасной коммуникации. Ещё в трёх абзацах можно рассказать, чем от неё отличается PGP.
При этом не очень нужно вдаваться в детали реализации длинной арифметики на машинах с конечной разрядностью — эти важные для реализации детали несущественны для понимания идеи и её слабых/сильных мест.

O>Просто текущие системы безопасности NT/Unix тащат свои корни с лохматых времен с мэйнфреймами, на которых сидели различные пользователи, и каждый пользователь делал какую нибудь одну, но очень важную для него вещь. В таком окружении та модель замечательно работает: там пользователь == защищаемые данные. Проблема в том что сейчас ее пытаются натянуть на однопользовательское окружение, в котором куча разных данных, совершенно различными "степенями секретности", но все они варятся в едином котле одного уровня привилегий.
Проблема вовсе не в этом. Проблема, конечно же, в том, что в юниксовые времена пользователь == программам, с которыми он работает. Ситуацию, когда пользователь выполняет под своими привилегиями потенциально враждебную программу, авторы этих систем безопасности не рассматривали вообще.
Как раз всякие степени секретности по отношению к данным прекрасно моделируются в модели NT — она ж недаром проходила военную сертификацию.

Плохо моделируются степени секретности по отношению к коду.
Да, ваше решение сильно поможет авторам DRM и DLP — в нём тупой пользователь не сможет нечаянно переслать секретный документ получателю с более низким уровнем доступа.
При условии, естественно, что классификация документа выполнена правильно. В этом и состоит основная проблема — данных возникает очень много.

O>А разделить уровни — непонятно как, потому что просто нет прямого и естественного пути их перегруппировать, причем так чтоб потом еще и можно было шарить друг с другом. Опять же старая модель безопасности предполагала наличие админа, который бы всем настроил пермишены и сказал кому что можно, а кому что нельзя. В нынешней же солянке информации на типичной системе никакой админ не разберется, кроме того она постоянно меняется. Для защиты данных нужна новая модель безопасности, которая защищает именно данные, а не какието произвольные сущности которые с конкретными данными однозначно и на словах увязать то сложно, а не то что формально описать и запрограммировать.
Модель безопасности NT построена вокруг того, что было доступно на момент разработки. То есть вокруг securable object. Её легко расширить на произвольные securable objects.

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

O>Дело не в том что они моделируются или не моделируются, дело в том что разработчики софта — ленивые люди по умолчанию, о безопасности они думают в последнюю очередь.
Правильно. О безопасности за них думают разработчики OC.

O>С какой палкой над ними не стой — никто не станет создавать сэндбокс для каждого документа/сайта и парится о том чтоб его данные не утекли кудато не туда (в соседний документ например).
Правильно. "Сэндбокс" создаёт админ — при помощи раздачи DACL на файлах. Это прекрасно работает в файловой системе, включая сетевые диски.
В правильно настроенной системе тупой пользователь не может дать доступ к секретному файлу другому тупому пользователю — потому что все ACL настроены админом.

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

O>Именно. Много данных, еще больше данных которые из них получается, граф взаимосвязи дико запутанный и никто за ним не следит вообще. ОС говорит — 'вот вам абстракции SD/token — накладывайте их на все ваши контейнеры данные', программеры — 'да ну нафиг, я лучше еще вот этот прочитанный вчера перед сном паттерн вверну и кнопочки сделаю в метрошном стиле'. Ни у кого нет конкретной ответственности — в результате бардак.
А, я кажется понял. В вашей системе безопасность будет обеспечиваться тем, что все данные уже засекьюрены, и написать банальный grep невозможно — потому что он работает с заранее неизвестным списком источников, никто из которых не почешется добавить grep в список разрешённых получателей.

O>>Дело не в том что они моделируются или не моделируются, дело в том что разработчики софта — ленивые люди по умолчанию, о безопасности они думают в последнюю очередь.
S>Правильно. О безопасности за них думают разработчики OC.

O>>С какой палкой над ними не стой — никто не станет создавать сэндбокс для каждого документа/сайта и парится о том чтоб его данные не утекли кудато не туда (в соседний документ например).
S>Правильно. "Сэндбокс" создаёт админ — при помощи раздачи DACL на файлах. Это прекрасно работает в файловой системе, включая сетевые диски.
S>В правильно настроенной системе тупой пользователь не может дать доступ к секретному файлу другому тупому пользователю — потому что все ACL настроены админом.
В том и проблема что в реальном мире
а) пользователь и данные — отдельные малопересекающиеся сущности
б) и хотя даклы это могут учесть, никто их правильно не настраивает.
Хорошая архитектура должна учитывать особенности суровой реальности, а не отстранятся от них в сферический вакуум.

O>>Именно. Много данных, еще больше данных которые из них получается, граф взаимосвязи дико запутанный и никто за ним не следит вообще. ОС говорит — 'вот вам абстракции SD/token — накладывайте их на все ваши контейнеры данные', программеры — 'да ну нафиг, я лучше еще вот этот прочитанный вчера перед сном паттерн вверну и кнопочки сделаю в метрошном стиле'. Ни у кого нет конкретной ответственности — в результате бардак.
S>А, я кажется понял. В вашей системе безопасность будет обеспечиваться тем, что все данные уже засекьюрены, и написать банальный grep невозможно — потому что он работает с заранее неизвестным списком источников, никто из которых не почешется добавить grep в список разрешённых получателей.
Нет, вы ровным счетом ничего не поняли. В моей системе любому коду можно делать с любыми данными все что угодно, до тех пор пока они не пойдут "наружу". Если данным с которым работает греп можно выводится на экран — они будут выведены. Фактически она дает даже больше свободы разработчикам, нежели существующая архитектура.

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

O>Нет, вы ровным счетом ничего не поняли.
Как объясняете — так и понял.
O>В моей системе любому коду можно делать с любыми данными все что угодно, до тех пор пока они не пойдут "наружу". Если данным с которым работает греп можно выводится на экран — они будут выведены.
Каким волшебным образом данные поймут, что они выводятся на экран? Греп у нас выдаёт результат какому-то другому процессу, а тот — третьему, затем — четвёртому.
Какой-то из них действительно выводит на экран. Только не на тот, на который смотрит пользователь.

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

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>"Мы" — это кто?
Я и Кернел

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

S>>Давайте начнём с простого.
S>>1. Вот у вас "данное" X, помеченное метаданными о ее происхождении и разрешениях. И "данное" Y, тоже помеченное метаданными о ее происхождении и разрешениях.
S>>Какие метаданные и разрешения будут у (X+Y)?
S>>2. Вот у вас клавиатура. Генерирует последовательности текста, помеченные личным пользовательским сертификатом. (Предположим, клавиатура умная и сама объединяет нажатия кнопок в тексты. А то вы явно не задумывались о том, как применить ЭЦП к, скажем, отдельному нажатию клавиши Shift).
S>>Какие "разрешения" будут у этих последовательностей текста? Можно ли их передавать, скажем, в интернет? Если нет, то как мне, например, пользоваться Скайпом? Если да, то что помешает набранному мной номеру кредитки утечь к фродерам?
O>А давайте вы сформулируете список вопросов, а я потом когда будет свободное время поразмыслю и сформулирую список ответов. Если конечно вам это правда интересно.
Вопрос, собственно, один: как это работает.
Поскольку никакого описания системы я не вижу, я не могу задать осмысленные вопросы к нему. Приходится спрашивать про те немногие вещи, которые вы упомянули.
Привычная нам низкоуровневая архитектура — это ассемблер, работающий с
а) кодом
б) данными.
При этом у нас более-менее всегда есть бинарные (реже — тернарные) операции, т.е. исходных данных у нас сразу два.
Допустим, теперь мы переходим от сырых данных к размеченным. Предположим, в общем духе фонНеймана, что код — это такие же данные, т.е. тоже оборудован разметкой.
Теперь нам надо для всех операций нашего ассемблера описать формулы, по которым получается итоговая разметка. Итоговые данные и так понятны — правила формирования результата imul [dest], eax придуманы до нас.
Велком — рассказывайте, какие операции вы собираетесь поддерживать, и как получается итоговая разметка.
Где-то в середине, очевидно, будет упоминание про те сочетания разметки исходных данных, при которых возникает AccessViolation.
А ближе к концу — упоминание про то, каким образом это собирается в замкнутую систему — что именно мешает злоумышленнику поставить свой апдейт в кернел.

O>Я и Кернел
Вот, заодно расскажете, что такое "Кернел".

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

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

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

S>>>А ближе к концу — упоминание про то, каким образом это собирается в замкнутую систему — что именно мешает злоумышленнику поставить свой апдейт в кернел.
O>>Код супервизора, отслеживающий все это должен защищаться по старинке — ring0, ring3.

S>Ну, как мы знаем из опыта, ring0, на который в 1988 возлагали столько надежд, себя не оправдал. Понятие "руткит" вам знакомо?

Ксати — Сейчас уже дальше зашли. В процессор. Там это пока не придумали как называется — ну типа не руткит же "-1".
Обидно что сертификаторы что-то там сертифицируют в софте и создают ложную иллюзию у потребителей, что типа тут закладок нет.
Как пробиться к тому кто понимает (поймет) что проблема атомная, ни как не удается. Ну мне покрайней мере.

S>>>Велком — рассказывайте, какие операции вы собираетесь поддерживать, и как получается итоговая разметка.
O>>Любая операция принимает на вход некие данные, делает над ними некие вычисления, результат которых зависит от самой операции и от входных данных. В результате операции появляются новые данные. Причем совершенно независимо от того что там за операция — imul, xor или SSEэшное перемножение векторов, 'принадлежность' информации которая получается в ее результате однозначно определяется как объединение принадлежностей информации принимаемой на вход (всех операндов, включая регистры и IO порты) и самой операции.

M>В примере перечислено то, что покроет 95% случаев. А вот специальные 5% инструкций доставят 95% проблем. И эти 5% — условные переходы. Вот как вы собираетесь размечать результат инструкции условного перехода? Все данные после перехода будут помечены тегом данных, которые использовались в условии? А не учитывать условные переходы нельзя, иначе можно создавать информацию из воздуха.
M>

M>var bankBits = bankData.asLongNumber(); //банковые данные
M>var myData = 0; //хакерские данные.

M>for (var i = 0; i < 10000; i++) {
M>  if (bankBits % 2 == 0)
M>    myData = myData * 2; //только хакерские данные
M>  else
M>    myData = myData * 2 + 1; //тоже хакерские данные

M>  // Чисто банковские данные. Или нет? Хотя не важно.
M>  bankBits /= 2;
M>}
M>myData.reverseBits();
M>

Отличный вопрос, пожалуй второй адекватный вопрос за всю историю ветки Я пожалуй над ним подумаю и отвечу как нить потом, если чтонить придумаю. Ну или посыплю голову пеплом А сейчас времени мало.
UPD1: посетил определенные места и таки кое что придумал. В гипотетической архитектуре не будет условных переходов Зато будут условные call'ы и чтонибудь
UPD2: с условными переходами я погорячился. Их можно оставить. И они правда будут накладывать теги на весь execution flow до.. возврата из обычного call'а, в котором находится текущий контекст. Т.о. на call'ы будет накладываться семантика ограничения скопа тегов порожденных условными переходами. Ну и само собой надо както будет сделать невозможным фокусы а-ля push/ret'а. Например — путем разделения стека переменных и стека адресов возврата. Это не единственное возможное решение, но его существование доказывает возможность решения вообще

M>Вот так на условных переходах теги теряются. Так что нужно бы все условные переходы трейсить и навешивать теги от условия перехода. Чую, так просто от этого не отделаться будет. Расползутся теги от условного перехода по всему приложению. Вот посмотрит браузер на clipping area для вывода чего-нибудь со странички банка, и все, на всем UI-выводе будет висеть тег этого банка. Даже после того, как я закрыл все окна от него.
Почему на всем UI выводе? Если говорим об экране — это лишь кусок видеопамяти, которая по сути ничем не отличается от физической памяти, кроме того что ее содержимое видно юзеру практически как есть Потому — просто эта память должна тегироваться как и обычная, а не обзываться "всем UI выводом".


M>Еще интересные темы с межпроцессным взаимодействием. Как тегируется новый процесс?
Сущность 'процесс' ортогональна тегированию. Вкратце — советую вам в этом контексте про процессы забыть. Но если уж не забывать, то изначально процесс — это прочитанные в память файлы (они, конечно же, тоже тегируются). Вот как была протегирована информация в файлах — так она и будет протегирована в процессе. Само собой АП процесс — не рассматривается как одна единственная сущность. А любая передача данных между процессами в плане передачи тегов должна быть эквивалентна прямому копированию данных в пределах одного процесса. Поэтому разделение на процессы совершенно не добавляет ничего в плане защиты данных от угона, а может использоваться только как мера локализации непреднамеренных повреждений памяти.

O>>Теперь попробуйте придумать вектор атаки, которая это обойдет.
M>Запросто. И даже теги на IP (instruction pointer) нам не помешают. Будем неторопясь сливать данные в свой "хакерский" домен. Отсутствие информации тоже может быть использовано в качестве информации!

M>

M>

M>Вот вам и вектор. Каждый читатель получает информацию из "хакерских данных". Если вдруг он прочитал данные с банковским тегом, он просто умирает (ничего никуда не сигналя!). Так как другие читатели знают протокол обмена, они могут восстановить "ошибки протокола" (т.е. не вышедших на связь в нужное время читателей).
M>Немного черной магии и данные извлекаются из "отсутствия данных". Чтобы с этим бороться, нужно либо анализировать как-то program flow и возможные affected vairables. Либо радостно развешивать теги на все псевдоглобальное, включая thread.sleep, сетевые взаимодействия и прочие источники, которые могут быть использованы для кражи данных. Но даже там я реализую sleep через большой цикл. И буду с интервалом ридеров пускать, а не ждать в самом ридере.
Код не разбирал, не очень есть время на это сейчас, отвечу по изложенному тексту.
Теги навешиваются на все, на самом низком уровне Прыгая по дереву абстракций вверх — от них не спрячешься. Статус процесса — это тоже переменная в памяти, и если ее вычисленное значение зависело от некоторых данных — на нем будет тот же тег.

M>Что-то мне кажется, что попытки бороться со всем этим приведут к решению "ставим теги на процесс". А это уже совсем не так интересно. Плюс результат будет похож на то, что уже есть сейчас. Всякие apparmor и прочие ограничители прав приложений (т.е. не только файловый доступ, а еще сокеты, системные ресурсы и т.п.).
Вообще моя предполагаемая архитектура если она имплементиться в хардваре — должна тегировать физическую память. Вообще всю, каждый байтик должен быть учтен. Причем память — это и ОЗУ, и диск, и регистры процессора. Да, на х86 это все накладывать будет накладно — я не спорю, потому и писал что тот проект — был лишь прототипом. Да и смысла нет — подобная модель при ее полноценной реализации (а не как большинство секурити продуктов на рынке, которые влегкую смогут обойти сами их разработчики) не оставит места для совместимости с любыми из существующих приложений.
А если его реализовывать софтварно — то только на сингулярити-образных ОС, в которых кстати уже настолько развитый контроль на памятью что там процессы и так работают в едином АП.

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

S>Простите, вы не могли бы поподробнее осветить этот момент с точки зрения PKI?
S>Каким образом эти "злоумышленники" останутся неизвестными?

Ну, как вариант, купят/украдут чужой ключ/сотрудника...

Вообще, "известные" в нашем мире подставных фирм и персон -- это некий информационный фантом.
Максиму на что можно рассчитывать: "при известном везении могут быть установленны заинтересованными в утановлении спецслужбами"

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>В качестве иллюстрации, продолжая образ с заборами и калитками, надо не строить заборы, а "не строить мосты". То есть что бы добратся куда то, надо построить сначала мост. Ну так как строить всегда дольше чем ломать, то при определенном условии может оказаться что мост построить будет просто "заразе" не под силу.

Дык игровая приставка "нинтендо" жеж. Всё ПО на картриджах с ПЗУ, и никаких вирусов и пиратов.
Трояны, правда, и прочие закладки, вполне возможны...

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>И почему никак будет не возможно выйти из этой машины в другую или в супервизор.

И что делать, если выйти надо? Скажем если мы хотим прцепить словарь к редактору и к читалке?

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

PD>Наверное, можно, а вот нужно ли ? Какие средства для этого понадобятся, сколько стоить будет, какие неудобства создаст ? Оправдывает ли это то увеличение безопасности, которое мы получим ?
Ну, как вариант, FS системы устроена так, что за сессию на диск пишется дифф, от стартового состояния, и при логоффе можно принять или непринять изменения.
В случае чего при рестарте просто откатываем систему к начальному состоянию.
А результаты работы (там комменты, фоты или код, скажем) остаются в облачном хранилище...

Тут, правда, есть две дырки.
1) зловредные веб-программы.
2) Исполняемый вредоносный код в данных, например в *.doc файлах.

Но для многих сценариев (1) относительно легко ограничить централизованно, а (2) вообще не нужны...

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

WH>То же самое касается drag&drop и copy&paste. Всё что нужно чтобы оболочка убедилась, что это делает пользователь руками. А не левый софт шалит.

А скрипты?

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

S>Но в целом сочетание идей CAS и CBS позволяют защищать и такие вещи. В частности, внезапно окажется, что порождённый приложением код выполняется под правами приложения, т.е. не может делать ничего нового по сравнению с приложением. Если приложению нельзя было открывать соединение по протоколу IRC, то и сгенерированному в нём коду будет нельзя.

А как же плагины?

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

S>Так и в IT — если дать отморозкам неограниченное время, то они сломают любую систему. Пароли — забрутфорсят, социалку — заинженерят. Заразят админу загрузочную флешку, и при штатном обслуживании сервака пропишут руткит прямо в бутсектор

Ну сломай "нинтендо" какое-нибудь с картриджами на ПЗУ...

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

ARK>Нет, ничего делить не будем. В системе будет некоторый набор прав — доступ в интернет, чтение из указанного хранилища (хранилище текстовых документов, аудиофайлов, видеофайлов, изображений, файлов автокада и т.п.), запись в указанное хранилище, создание дочерних процессов, установка приложений и т.д. Также будет несколько стандартных групп прав — "браузер", "просмотрщик картинок", "текстовый редактор", "среда разработки", etc. Каждое конкретное приложение при инсталляции должно будет отнести себя к некоторой группе и/или потребовать отдельный/дополнительный набор прав. Приложения, подписанные сертификатом, можно установить без предупреждений. Неподписанные должны явно получить одобрение администратора. Примерно так.

Ну, то есть просто пользователь, просто няшную прогу поставить, даже на "попробовать" не сможет?
Тогда можно прсто взять NT, юзера с провами пожиже, и для всего "лишнего" пусть зовёт админа. И безопасная ОС УЖН В КАРМАНЕ!!!

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

WH>1)Плагин при всём желании не сможет сделать больше, чем позволено приложению.
А если плагину надо больше?
Скажем приложение фотошоп, а плагин -- драйвер сканера?

KV>>или функциональность которых требует обмена инфой с соседними без участия пользователя?
WH>А можно пример?

Я щёлкаю по слове в тексте и хочу перевод в электронном словаре. А словарь вдруг хочет не только слово, но и контекст вокруг.
Что делаем?

Здравствуйте, Erop, Вы писали:
E>Ну сломай "нинтендо" какое-нибудь с картриджами на ПЗУ...
Это не тот нинтендо, к которому взломанными картриджами по 130 рублей торговали?

Здравствуйте, Erop, Вы писали:
E>Ну, как вариант, купят/украдут чужой ключ/сотрудника...
Я правильно понимаю, что со схемой отзыва ключей вы не знакомы?

E>Вообще, "известные" в нашем мире подставных фирм и персон -- это некий информационный фантом.
Не знаю я вашего фантомного мира. А в нашем сертификаты по факту очень эффективно предотвращают проблемы имперсонации.

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

S>Это не тот нинтендо, к которому взломанными картриджами по 130 рублей торговали?

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

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

S>Я правильно понимаю, что со схемой отзыва ключей вы не знакомы?
Так это пока ещё заметят и отзовут...
Вечных взломов же не бывает?

S>Не знаю я вашего фантомного мира. А в нашем сертификаты по факту очень эффективно предотвращают проблемы имперсонации.
Да-да-да. Ща, кино краденное из-под ДРМ досмотюр и сразу поверю

M>>>Вот так на условных переходах теги теряются. Так что нужно бы все условные переходы трейсить и навешивать теги от условия перехода. Чую, так просто от этого не отделаться будет. Расползутся теги от условного перехода по всему приложению. Вот посмотрит браузер на clipping area для вывода чего-нибудь со странички банка, и все, на всем UI-выводе будет висеть тег этого банка. Даже после того, как я закрыл все окна от него.
O>>Почему на всем UI выводе?
M>А так принято в типичной архитектуре на данный момент. Есть UI-поток, в котором выполняются все операции с графикой. И стоит ему сделать что-нибудь условное (например, прочитать атрибут Visible на каком-нибудь виджете, зависящий от данных банка) и все — на IP есть тег. Скорее всего, очистка тега при выходе из метода поможет бороться с этой проблемой. Что-то подобное может быть и внутри видео-драйверов, например.
Все операции с графикой не более чем рисование пикселей что тождественно эквивалентно равно модификации байтов видеопамяти во фреймбуффере. Вобщем — вообще никакой разницы с работой с обычной памятью тут нету.


M>>>Еще интересные темы с межпроцессным взаимодействием. Как тегируется новый процесс?
O>>Сущность 'процесс' ортогональна тегированию. Вкратце — советую вам в этом контексте про процессы забыть.
M>Зачем забывать? Они связаны все с тем же специальным случаем: регистром IP. Набор инструкций для него очень специфичен и очень сильно отличается от инструкций работы с другими регистрами и памятью. Как минимум нужно рассматривать, что с ним происходит при создании нового процесса (наследуется или нет).
Вот вы опять пытаетесь вылезти по лестнице абстракций из колодца в котором я сижу
В ключе контекста значение имеет
1) Адрес, куда указывает IP на момент исполнения инструкции. Процессор исполнил инструкцию — автоматически модификировали тег согласно тегам операндов инструкции и физического адреса где эта инструкция лежит
2) Текущий скоуп jmp-тегов (из вашего предыдущего сообщения). Его шедулер будет переключать при переключении контекста. Наличие некоего гипервизора, управляющего базой тегов, я совершенно не исключаю. Впрочем можно даже тут обойтись без гипервизора, если ввести в CPU систему команд для переключения задач, которой наконец-то, все начнут пользоваться..

M>Этот связано с удобством разработки и использования. И именно на межпроцессное взаимодействие я буду смотреть в первую очередь для поиска способов очистить данные от тегов.
Ну вы то смотрите, но моя идея изначально про процессы вообще никакого понятия не имеет. Примерно так же как о них не имеет понятия CPU, а моя система изначально задумана как гипервизор над тем, что из себя обычно CPU представляет + над памятью и железом. Причем если CPU в каком то смысле все еще "занимается" процессами — механизмом трансляции виртуальных адресов в физические, то моя система будет контролировать лишь операции над уже оттранслированными адресами физ. памяти и устройствами ввода вывода, в которую информация с этой памяти будет читаться/писаться. То есть разделение на процессы — ей вообще по барабану.

M>Плюс с процессами/потоками связаны некоторые вещи, которые очень сложно смоделировать в модели "функциональная зависимость от данных". Например, зависимость от текущего времени (таймауты, таймеры). С обычной памятью и кодом (при линейном потоке выполнения) проблем как раз нет. Но "текущая точка выполнения программы" тоже является очень важными данными, через которую я и буду атаковать. Банальное "я закрыл сокет за минуту" и "я не закрывал сокет больше двух минут" может служить для передачи бита данных. Кстати, обратите внимание, даже _закрытие_ сокета является передачей данных. Не проблема, но интересный момент.
Закрытие сокета — это само собой сложный процесс, который изначально представляет собой вызов closesocket'а, а оконечно — запись байтиков FIN/RST пакета в сетевую карту, для отправки оного в сеть. И вот на этой то записи мы его и прикроем, ибо сама это запись является продуктов графа исполнения ведущего гдето из апликухи,и весь этот граф — тегируется насквозь.
Терминейт процесса — это не более чем терминейт всех его потоков. Терминейт потока — это всего лишь модификация одного байта и одного дворда в ETHREAD . Опрос состояния потока при помощи WaitFor* или GetExitCodeThread — это не более чем операции чтения этих байтов. Даже если они будут изначально вызваны из жаваскрипта в контексте браузера — в конечном итоге результат операции будет привязан к тому, кто произвел записи в эти байты, то есть завершил процесс. Даже завершение процесс сами себя — это ровно такая же операция записи в эти байты. Потому — давайте ка со своих деревьев абстрагированных сущностей ко мне в колодец, тут сыро и весело
Про таймауты, а точнее — зажор CPU time — вопрос на самом деле интересный, я о нем уже думал, но конкретного решения пока не осмалюсь выложить.

M>>>Немного черной магии и данные извлекаются из "отсутствия данных". Чтобы с этим бороться, нужно либо анализировать как-то program flow и возможные affected vairables. Либо радостно развешивать теги на все псевдоглобальное, включая thread.sleep, сетевые взаимодействия и прочие источники, которые могут быть использованы для кражи данных. Но даже там я реализую sleep через большой цикл. И буду с интервалом ридеров пускать, а не ждать в самом ридере.
O>>Код не разбирал, не очень есть время на это сейчас, отвечу по изложенному тексту.
O>>Теги навешиваются на все, на самом низком уровне Прыгая по дереву абстракций вверх — от них не спрячешься.

M>Буду ждать, пока разберете. И теги не помогут Попробую пояснить, что за трюк там используется на более простом примере.
Ну, ждите..

M>Получается, что для учета "зависит ли значение от другого значения" (в императивной модели) нужно знать не только те команды, которые выполнились, но и те, которые _не выполнились_ (но могли выполниться). Иначе мы можем "частично очищать данные".
Но не выполнились-то они в результате какой то логики Я подозреваю что в конечном итоге возможно будет создать некий эффект, наподобии квантовой запутанности, когда с двух сторон имеем одну и туже последовательность случайных чисел, которая вроде как мгновенно-синхронна, но передать информацию при помощи этого не получается

M>>>Что-то мне кажется, что попытки бороться со всем этим приведут к решению "ставим теги на процесс". А это уже совсем не так интересно. Плюс результат будет похож на то, что уже есть сейчас. Всякие apparmor и прочие ограничители прав приложений (т.е. не только файловый доступ, а еще сокеты, системные ресурсы и т.п.).
O>>Вообще моя предполагаемая архитектура если она имплементиться в хардваре — должна тегировать физическую память. Вообще всю, каждый байтик должен быть учтен.
M>А вопрос даже не в том, как это реализовать. Нужно показывать, что это стоит реализовывать. У меня есть сильные подозрения, что после открытия файла теги с этого файла распространятся по 90% приложения (через Instruction Pointer или IO monad) в течение пары минут. При такой скорости распространения практического смысла в тегировании каждой ячейки памяти нет, можно сразу на приложение вешать теги (да, да IP очень мешает). Поэтому нужно показывать, что можно сделать такую архитектуру, в которой можно эффективно ограничивать область распространения тегов. Это должно быть практично, причем как для маленьких приложений, так и для больших. Во всех разных моделях (UI, сервер и т.п.).
По факту на тестовом приложении — не распространяются. До тестирования на полноценном приложении — эксперимент не дошел. Разумеется дизайн и средста разработки такой оси и приложений под такую ось должны будут учитывать эту специфику, во избежание геморроя.

M>P.S. Забавный сценарий для размышления. Я кладу на экран две кнопки (в одно и то же место). В зависимости от условия, я убираю первую или вторую кнопку. В какой-то момент пользователь нажимает оставшуюся кнопку и я получаю информацию о том, какое же было значение. Формально идет только пользовательский ввод. Поможет ли здесь тегирование и если поможет, то как? (Вот так и появится тег данных на всем UI, как я и предполагал выше). А если это в виде игры оформить, вообще круто будет! Пользователь в процессе игры будет нам данные от тегов очищать. Процесс передачи system->user->system.
В смысле плохой код просит пользователя нажать заданную кнопку в заданном приложении и тем самым передает информацию? Я уже писал что атаки типа попросить юзера ввести секретную информацию моим подходом не решаются на 100%, но можно уменьшить риск путем автоматического распрзнавания информации, которую тот вводит аналогично DLP системам, применяемых обычно на периметрах.