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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 источников. Вы уверены что у вас столько уникальных сайтов в хистори наберется?
А у кого будут права на запись в базу идентификаторов?

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.в) У пользователя системы должен быть личный сертификат, с помощью которого клава/мышь/тач так же будут тегировать весь его ввод, с возможностью криптографической его верификации в случае необходимости (банковская транзакция, заказ авиабилета, пост в КЫВТ...)

Здравствуйте, 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.в) У пользователя системы должен быть личный сертификат, с помощью которого клава/мышь/тач так же будут тегировать весь его ввод, с возможностью криптографической его верификации в случае необходимости (банковская транзакция, заказ авиабилета, пост в КЫВТ...)
Это всё малоинтересные подробности.
Давайте поймём простую вещь: вот у меня есть, допустим, авиабилет, купленный на сайте аэрофлота. У меня, допустим, есть приложение А — "календарь", с разрешением синхронизоваться с моим смартфоном. Для упрощения предположим, что это — веб приложение, т.е. просто другой сайт. Есть сценарий "добавить данные авиабилета в календарь". Естественно, мы предполагаем, что само приложение календаря было разработано независимым вендором через пять лет после того, как сайт аэрофлота был запущен.
Что должен сделать и кто чтобы разрешить пользователю выполнить этот сценарий?