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


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

M>Этот связано с удобством разработки и использования. И именно на межпроцессное взаимодействие я буду смотреть в первую очередь для поиска способов очистить данные от тегов.
Ну вы то смотрите, но моя идея изначально про процессы вообще никакого понятия не имеет.

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

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

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


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

M>Этот связано с удобством разработки и использования. И именно на межпроцессное взаимодействие я буду смотреть в первую очередь для поиска способов очистить данные от тегов.
Ну вы то смотрите, но моя идея изначально про процессы вообще никакого понятия не имеет.

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

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