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