ошибка обращения к .NET сборке в режиме Server

[gl00mie]

Цитата:

Сообщение от sukhanchik

получается (если я правильно понял по аглицки):
1. Проверка, что код имеет соответствующее разрешение по стеку вызовов (интересно - какой стек вызовов должен быть, чтобы он не прошел проверку - просто без этого кода?)

Насколько я понимаю, принцип примерно такой:

• по ходу выполнения кода клиентом API запрашиваются разрешения на выполнение тех или иных действий (создается экземпляр CodeAccessPermission и дергается assert()) - это приводит к тому, что в стеке вызовов создается некий security cookie (видел такой термин в отладочной информации ядра 4-ки), соответствующий запрошенным разрешениям
• выше по стеку вызовов клиента API вызывается код, который использует некий API, требующий разрешений - при этом владелец API создает соотв. экземпляр класса-наследника CodeAccessPermission и дергает на нем метод demand()
• ядро пробегается по стеку вызовов вниз и ищет соотв. security cookie; соответствие определяется тем, что созданному во владельце API экземпляру класса-наследника CodeAccessPermission в метод isSubsetOf() подсовываются экземпляры запрошенных разрешений (созданных в клиенте API классов-наследников CodeAccessPermission)
• если в какой-то момент созданный владельцем API экземпляр вернет из isSubsetOf() true, то считается, что разрешение найдено, и дальше выполняется код API, следующий за вызовом demand()
• если на протяжении всего стека вызовов клиента API подходящий security cookie не найден, ядро выбрасывает исключение
• если код клиента API выходит из метода, в котором было запрошено разрешение (вызван assert()), то на созданных разрешениях вызывается revertAssert(), и security cookie удаляются; revertAssert() можно, конечно, вызвать и раньше, не дожидаясь выхода из метода. Таким образом, код клиента API, в который вернется управление из метода, запросившего разрешение, уже не сможет воспользоваться этим разрешением, потому что оно будет отсутствовать в стеке вызовов

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

Цитата:

Сообщение от sukhanchik

2. Проверка, что вызов опасного API был вызван из "доверенного" кода, сохраненного в АОТ. А какой код не доверенный? Не сохраненный в АОТ?. Интересно - во-первых - как такой код исполняется (в Аксапте) и даже не столько это, а сколько то, что в Аксапте так просто создать код, сохраненный в АОТ и вызвать "опасный" код оттуда - что при желании так сделать - это сделать все равно можно.

Насколько я понимаю, "ноги" этих разрешений растут из .NET с его managed code. Не забывайте, что как код Х++ может вызывать .NET-сборки, так и внешний код может вызывать код Х++ через Business Connector, может, дело в этом...

Цитата:

Сообщение от sukhanchik

3. Проверка, что код, вызывающий опасное API - вызывается это на той же стороне (клиент/сервер), что и само API. Вот это совсем непонятно.. Во первых вызвать код там где надо не составляет труда, а во-вторых - да какая разница?

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

Цитата:

Сообщение от sukhanchik

Но тут и вопрос - если самому писать - то зачем тогда поддержка на уровне ядра?

Ради взаимодействия с CLR

[sukhanchik]

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

Цитата:

Сообщение от gl00mie

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

Ну, логично - что разрешение должно быть получено раньше, чем использован соотв. API. Понятно - что это является "синхронизацией" с .NET. Просто пока не могу в голове смоделировать контрпример, в каких случаях этот механизм разрешений именно защитит пользователя от исполнения "опасного" кода. Т.е. представим себе - что все вызовы "опасных" функций обрамляются в разрешения. Чем такой "обрамленный" код отличается от "необрамленного"? Только кол-вом кода, генерацией security cookie и т.д. Т.е. все равно кол-во "опасных" вызовов при этом не уменьшится. Не вижу предпосылок уменьшения использования "опасного" кода при этом программисту. Ну если нет аналога функции WinAPI::findWindow (к примеру) - а вызвать надо то хоть тресни - программисту придется ее вызвать - хоть с "обрамлением", хоть с бантиками, хоть завернутую в подарочную упаковку.

Цитата:

Сообщение от gl00mie

Насколько я понимаю, "ноги" этих разрешений растут из .NET с его managed code. Не забывайте, что как код Х++ может вызывать .NET-сборки, так и внешний код может вызывать код Х++ через Business Connector, может, дело в этом...

Об этом не подумал, спасибо. С этим согласен. В свое время в Access-е столкнулся с вызовом SQL-VBA-SQL и VBA-SQL-VBA - в этой конструкции Access просто вылетал с предложением послать все в MS.

Цитата:

Сообщение от gl00mie

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

Ну скажем это ограничение - оно условно искусственное. Условно - в том плане - что нет разницы (в техническом плане) между исполнением кода на клиенте и на сервере. В обоих случаях посылается запрос на БД (мы ж не сравниваем исполнение кода на сервере БД и на клиенте). А искусственное - т.к. логично ограничить разработчика - дабы у него не возникало желания весь объем данных тянуть с клиента на сервер БД - т.к. каналы связи АОС-БД и клиент-БД - не сравнимы (в нормальной сети) по "толщине", надежности и т.д.
Вот формы на сервере - не отобразишь. Но с другой стороны - это и никому не нужно - а если было бы нужно - то тоже я думаю - что можно было бы сделать.

Цитата:

Сообщение от gl00mie

Ради взаимодействия с CLR

.NET - рулит и все такое... Понятно...

В общем - резюмируя могу сказать - что пока по крайней мере можно предположить защиту от повторных вызовов X++ - .NET - X++. Хотя фантазии пока хватает на пределе. Т.е. конкретно для этого случая - можно заложить разрешения. Во всем остальном, особенно с ограничениями на серверный/клиентский вызов - не очень понятно. Не всегда ж "опасные" функции вызываются через .NET - иногда и сами по себе .

[gl00mie]

Цитата:

Сообщение от sukhanchik

пока не могу в голове смоделировать контрпример, в каких случаях этот механизм разрешений именно защитит пользователя от исполнения "опасного" кода. Т.е. представим себе - что все вызовы "опасных" функций обрамляются в разрешения. Чем такой "обрамленный" код отличается от "необрамленного"? Только кол-вом кода, генерацией security cookie и т.д. Т.е. все равно кол-во "опасных" вызовов при этом не уменьшится.

Здесь принципиально то, что контроль над использованием опасных API выносится с уровня приложения на уровень ядра и становится, таким образом, доступен пользователю (администратору). Так, к примеру, на уровень "ядра" вынесены различные настройки параметров безопасности MSIE, и можно вручную или групповыми политиками настроить, что делать можно, а чего нельзя, не ковыряясь в каждом отдельном сайте, страничке или Java-скрипте. Аналогично, может быть, в будущих версиях Аксапты можно будет настраивать на уровне конфигурационной утилиты, какие именно "опасные API" можно использовать, к каким ресурсам и какого рода доступ можно предоставлять с их помощью.

Цитата:

Сообщение от sukhanchik

нет разницы (в техническом плане) между исполнением кода на клиенте и на сервере. В обоих случаях посылается запрос на БД (мы ж не сравниваем исполнение кода на сервере БД и на клиенте).

Я тут подумал, что все же разница есть - именно применительно к разрешениям Предположим, что код приложения должен обратиться к какому-то файлу - для этого он запрашивает FileIOPermission с указанием, к какому именно файлу и в каком режиме (чтение, запись, добавление) код хочет обратиться. Если бы можно было получить разрешение на клиенте, а использовать его на сервере, то получилось бы, что проверка прошла бы для одного объекта (файла по тому пути, как он видится с машины клиента), а реальный доступ был бы осуществлен в общем случае к совершенно другому объекту (файлу по тому пути, как он видится на сервере, даже если это в точности такой же путь, что и на клиенте). Очевидно, такой ситуации допускать нельзя: к какому объекту запросили (и получили) разрешение на доступ, к тому и применяйте это разрешение. Отсюда, видимо, и ограничение, касающееся использования разрешения на том же уровне (на клиенте либо на сервере), на каком оно было получено.

Цитата:

Сообщение от sukhanchik

Ккаким образом предполагается (предполагалось) контролировать - в каких условиях используется "опасное" API?

В примере защиты своего "опасного API" с помощью Code Access Security из Writing Secure X++ Code при запросе разрешения в конструктор класса-наследника CodeAccessPermission передаются некие данные, используемые затем для проверки наличия разрешения в ходе использования "опасного API". Так вот, этот пример, конечно, абстрактный, но, скажем, применительно к тому же FileIOPermission он уже обретает конкретику. Клиент API помимо типа разрешения еще и указывает, доступ какого рода и к какому именно ресурсу он хочет получить с помощью API. При этом "владелец" API может, скажем, по неким настройкам проверить, стоит ли давать доступ к этому ресурсу, например, можно ли пользователю, связанному с текущей сессией, давать доступ к тому или иному файлу на сервере от имени пользователя, под учетной записью которого работает AOS.

Цитата:

Сообщение от sukhanchik

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

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

[sukhanchik]

Цитата:

Сообщение от gl00mie

Здесь принципиально то, что контроль над использованием опасных API выносится с уровня приложения на уровень ядра и становится, таким образом, доступен пользователю (администратору). Так, к примеру, на уровень "ядра" вынесены различные настройки параметров безопасности MSIE, и можно вручную или групповыми политиками настроить, что делать можно, а чего нельзя, не ковыряясь в каждом отдельном сайте, страничке или Java-скрипте. Аналогично, может быть, в будущих версиях Аксапты можно будет настраивать на уровне конфигурационной утилиты, какие именно "опасные API" можно использовать, к каким ресурсам и какого рода доступ можно предоставлять с их помощью.

Если так - то теория ясна. Осталось посмотреть как это будет реализовано на практике. Т.е. пока в 4-ке по сути положено начало, а развитие следует ожидать дальше.... Хотя если честно - я тяжело себе представляю ограничение по использованию тех же WinAPI-функций - ибо среди них есть весьма мирные (типа вернуть текущее имя пользователя), а есть более опасные (типа завершения работы системы). Конечно я немного утрирую - но вряд ли будет в конфигурации всех API-функций. Максимум - сам факт их вызова. Ну если только на уровне самих функций будет определен уровень разрешения, который должен быть для возможности их запуска (аналогично свойству пункта меню NeedAccessLevel). Но в целом - понятно - т.е. пока закладывается фундамент дома - а какие башенки будут построены - будет видно в следующих версиях.

Цитата:

Сообщение от gl00mie

Я тут подумал, что все же разница есть - именно применительно к разрешениям Предположим, что код приложения должен обратиться к какому-то файлу - для этого он запрашивает FileIOPermission с указанием, к какому именно файлу и в каком режиме (чтение, запись, добавление) код хочет обратиться. Если бы можно было получить разрешение на клиенте, а использовать его на сервере, то получилось бы, что проверка прошла бы для одного объекта (файла по тому пути, как он видится с машины клиента), а реальный доступ был бы осуществлен в общем случае к совершенно другому объекту (файлу по тому пути, как он видится на сервере, даже если это в точности такой же путь, что и на клиенте). Очевидно, такой ситуации допускать нельзя: к какому объекту запросили (и получили) разрешение на доступ, к тому и применяйте это разрешение. Отсюда, видимо, и ограничение, касающееся использования разрешения на том же уровне (на клиенте либо на сервере), на каком оно было получено.

Логика-то ясна... но "красивые и чистые" мысли разбиваются о "грязную" необходимость сокращения нагрузки на клиента (да и вообще на сетевой траффик). Т.е. в то время когда все учат выносить всю работу с БД на сервер (что логично) - мы с т.з. безопасности делаем это на клиенте, т.к. именно клиент выбирает файл для импорта. Было бы логично как раз сборки .NET, dll-ки как раз подключать к серверу, хотя бы с т.з. проверки прав доступа. Одно дело - дать права только пользователю, от имени которого запущен АОС и другое дело - дать права некому полноценному конкретному пользователю (да еще если их много). Хотя - с т.з. безопасности - может последнее и правильно - по крайней мере контролируемо.

Цитата:

Сообщение от gl00mie

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

Просто у меня отношение к защите и безопасности - такое: Защита некоего действия не должна это действие отменять или запрещать.
Т.е. бессмысленно в рамках охраны человека его убивать, дабы это не сделали другие.
Бессмысленно в рамках защиты сервера полностью отключать к нему доступ.
Бессмысленно в рамках поддержки делать такую бюрократическую проволочку - что от момента заявки пользователя (в случае, если это останавливает его работу) до момента устранения заявки проходит такое кол-во времени, что ставит под сомнение необходимость его работы в системе.

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

[gl00mie]

Цитата:

Сообщение от sukhanchik

я тяжело себе представляю ограничение по использованию тех же WinAPI-функций - ибо среди них есть весьма мирные (типа вернуть текущее имя пользователя), а есть более опасные (типа завершения работы системы). Конечно я немного утрирую - но вряд ли будет в конфигурации всех API-функций. Максимум - сам факт их вызова. Ну если только на уровне самих функций будет определен уровень разрешения, который должен быть для возможности их запуска (аналогично свойству пункта меню NeedAccessLevel).

Логика разработчиков и вообще "политика партии" может быть такая: зачем вам использовать WinAPI, если есть .NET? А в .NET вполне даже можно повесить разного рода ограничения и на каждый отдельный класс, и на каждый отдельный конструктор класса, и на каждый отдельный метод класса и рулить этим всем, опять же, через какие-нить групповые политики, см., например, SecurityPermissionAttribute, а также SecurityPermissionFlag. А использование WinAPI может со временем стать не соответствующим "политике партии" подходом, расцениваемым как потенциально опасный и рекомендуемым к отключению в настройках безопасности (если потом можно будет рулить настройками, какие CodeAccessPermission разрешать, а какие - нет).

Цитата:

Сообщение от sukhanchik

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

К вопросам импорта/экспорта данных можно подходить по-разному. К примеру, в теме экспорт в шаблон Excel обсуждался один из подходов: запихнуть данные в какой-нить Map, запаковать в контейнер и передать на другой уровень (с клиента на сервер или наоборот), а там уже обрабатывать - в базу импортировать или, там, в тот же Excel выводить...

Цитата:

Сообщение от sukhanchik

Просто у меня отношение к защите и безопасности - такое: Защита некоего действия не должна это действие отменять или запрещать.

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

Цитата:

Сообщение от sukhanchik

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

Вспоминается 4-е письмо о стратегии Джоэла Спольски:

Цитата:

The developers who put a lot of effort into optimizing things and making them tight and fast will wake up to discover that effort was, more or less, wasted, or, at the very least, you could say that it “conferred no long term competitive advantage,” if you’re the kind of person who talks like an economist.
The developers who ignored performance and blasted ahead adding cool features to their applications will, in the long run, have better applications.

Это к тому, что если создать сложную бюрократическую систему в рамках поддержки клиентов, то ее всегда можно улучшить и ускорить - зато вы сможете на основе собранных данных получать значения KPI во всех возможных разрезах и показывать результаты руководству, выбивая новый бюджет. А если такую систему не создать, то можно биться как рыба об лед, но любое недовольство клиента, который обратится на уровень выше, может привести к резонному вопросу руководства: "чем вы тут вообще, собственно, занимаетесь?!" - а ответить-то будет нечего

Цитата:

Сообщение от sukhanchik

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

Во-первых, это не совсем так: если есть определенные требования по безопасности, которые проверяются лишь на сервере, это вовсе не означает, что логику работы надо выносить на клиента - просто для того, чтобы не проходить дополнительные проверки. Во-вторых, с точки зрения безопасности подумайте вот о чем: тенденции развития той же Аксапты таковы, что значительная часть взаимодействия с конечными пользователями выносится на корпоративный портал. Это, с одной стороны, позволяет упростить доступ к системе (вспомним хотя бы тему Как дать доступ к Аксапте внешним пользователям?), с другой, сэкономить на лицензиях, поскольку лицензии на Business Connector на порядок дешевле "обычных" пользовательских лицензий. В то же время переход на Web-интерфейс означает значительное ослабление контроля за тем, что может и чего не может делать клиент: если я работаю через GUI-клиента, мне очень проблематично контролировать, что он там передает AOS'у, какие проверки вызывает и т.п., если же я работаю через Web-интерфейс, то я могу, к примеру, вручную набить и отправить http-запрос или даже могу поставить программку вроде Proxomitron и с ее помощью на лету кромсать, как мне вздумается, Java-скрипты в страничках, которые генерит движок корпоративного портала, формируя для меня тот самый Web-интерфейс, т.е. фактически могу произвольно относительно легко вмешиваться в работу клиентской части системы. Можно привести простой пример: есть такая служба размещения файлов в сети rapidshare, которая при скачивании файлов, если не купить premium-доступ, заставляет ждать энное количество секунд. Задержа прежде была реализована достаточно банально: в страничку, генерившуюся при запросе на скачивание файла, внедрялся Java-скрипт, который крутил пустой цикл указанное количество секунд и лишь затем показывал ссылку для скачивания. Обойти это было проще простого: с помощью того же Proxomitron'а делался фильтр, который по regexp'у искал этот скрипт и подменял начальное значение счетчика пустых циклов на ноль. В результате при доступе к rapidshare через Proxomitron в браузере сразу же показывалась ссылка для скачивания - без томительного ожидания. Т.е. фактически происходило вмешательство в логику работы клиентской части сервиса rapidshare (потом эту лазейку прикрыли, опять-таки, за счет дополнительной проверки на сервере). А теперь представьте, что таким же образом кто-то меняет логику работы клиентской части Аксапты, получая доступ к системе через корпоративный портал...

[sukhanchik]

Цитата:

Сообщение от gl00mie

Логика разработчиков и вообще "политика партии" может быть такая: зачем вам использовать WinAPI, если есть .NET? А в .NET вполне даже можно повесить разного рода ограничения и на каждый отдельный класс, и на каждый отдельный конструктор класса, и на каждый отдельный метод класса и рулить этим всем, опять же, через какие-нить групповые политики .... А использование WinAPI может со временем стать не соответствующим "политике партии" подходом, расцениваемым как потенциально опасный и рекомендуемым к отключению в настройках безопасности (если потом можно будет рулить настройками, какие CodeAccessPermission разрешать, а какие - нет).

Если смотреть на .NET в рамках отказа от WinAPI - то, безусловно, это позиция имеет право на жизнь. В конце концов .NET и создавали для создание машинно-независимых приложений.
В этом ключе вспоминается переход между DOS и Windows. Как было просто в DOSе и как сразу стали запрещены резидентные DOS-программы в Windows. В общем-то да - при эволюции всегда новое кажется ненужным, лишним и мешающим,однако - сейчас уже многие забыли или не знают как писать резидентные программы под DOS. И вроде как все без этого научились жить - в смысле приспособились к Windows. Значит и .NET приспособимся.

Цитата:

Сообщение от gl00mie

К вопросам импорта/экспорта данных можно подходить по-разному.

Это понятно - что всегда можно обойти... Просто всегда напрягает - что знакомая и уже давно привычная конструкция перестает работать, из-за непонятного тебе нового механизма. Но как выше уже было сказано - в этом и состоит эволюционирование. Одни (МС) эволюционируют, другие (программисты) - приспосабливаются.

Цитата:

Сообщение от gl00mie

тенденции развития той же Аксапты таковы, что значительная часть взаимодействия с конечными пользователями выносится на корпоративный портал. Это, с одной стороны, позволяет упростить доступ к системе ..., с другой, сэкономить на лицензиях, поскольку лицензии на Business Connector на порядок дешевле "обычных" пользовательских лицензий. В то же время переход на Web-интерфейс означает значительное ослабление контроля за тем, что может и чего не может делать клиент

Ну если рассуждать с этой т.з. - то да, конечно - безопасность должна быть выше.
В принципе - понятно - что все развивается - и 4-ка - это некий полуфабрикат той же 5-ки (2009), которая в свою очередь будет бета-версией для 6-рки и только где-то к 7-й версии все боле менее устаканится.
Просто по сравнению с 4-ркой - 3-шка выглядела условно-законченным продуктом, в котором технологии были развиты до некоего потолка и закончены. И упор делался на функционал.
А 4-рка - это первые предпосылки к 7-й версии .

В общем-то понятно. Надо просто на 4-ку смотреть не столько как на развитие 3-шки, сколько на новую систему, смоделированную на базе 3-шки. А у новой системы и другая тенденция развития (на портал).
Что ж - бум пересматривать взгляды и ломать стереотипы