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 и прочие ограничители прав приложений (т.е. не только файловый доступ, а еще сокеты, системные ресурсы и т.п.).

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>Ну, то есть просто пользователь, просто няшную прогу поставить, даже на "попробовать" не сможет?

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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.

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 системам, применяемых обычно на периметрах.