Последовательность загрузки приложений в AutoCAD с учетом SECURELOAD

[Александр Ривилис]

Последовательность загрузки приложений в AutoCAD с учетом SECURELOAD

[Андрей Бушман]

Чего-то с версиями акада понапутано, насколько я вижу... Везде вместо AutoCAD 2012 SP 1 должен быть AutoCAD 2013 SP 1

[Александр Ривилис]

Да. В оригинале статьи тоже самое.

[Андрей Бушман]

Отсутствует информация о том, что пакет обновления SP1 для AutoCAD 2013 содержал ошибки, приводившие к аварийному завершению работы AutoCAD. В связи с этим Autodesk удалила со своего сайта обновление SP1, заменив его на SP1.1.

[Андрей Бушман]

Так же неплохо было бы сообщить, что accoreconsole "работает" с ключом /nolisp через одно место (почему-то я даже не удивился этому)... Смотрел в AutoCAD 2013 и 2016.

Попробуйте, запустив

accoreconsole /nolisp

выполнить сначала

(princ "123")

затем

(+ 2 5)

Первая команда отработает. Вторая - нет. Т.о. налицо неполная блокировка использования LISP в accoreconsole.

[Андрей Бушман]

для значений 1 и 2 системной переменной SECURELOAD написана муть. В справке написано нормально.

[Андрей Бушман]

Ключ "/nolisp", появившийся в AutoCAD 2013, переименован в "/safemode" и теперь обрабатывает не только lsp / fas / vlx, но и вообще все исполняемые файлы, которые можно загрузить в AutoCAD. Использование этого ключа запустит AutoCAD в минимально возможной функциональности и позволит изменить AUTOLOADPATH в параметрах AutoCAD'a. Если AutoCAD запущен с этим ключом, то никакое выполнение кода невозможно.

не AUTOLOADPATH, но SECURELOAD.

[Пашин Евгений]

Это ж что получается - SECURELOAD=0 и AutoCAD никаких сообщений-предупреждений не выводит?! Прелюбопытно.

[Андрей Бушман]

Это ж что получается - SECURELOAD=0 и AutoCAD никаких сообщений-предупреждений не выводит?! Прелюбопытно.

Ничего любопытного. Лучше бы этого варианта не было вовсе.

[Алексей Кулик]

Это ж что получается - SECURELOAD=0 и AutoCAD никаких сообщений-предупреждений не выводит?! Прелюбопытно.

Ничего любопытного. Лучше бы этого варианта не было вовсе.

Кому как.

[Андрей Бушман]

Кому как.

Любители создавать себе проблемы на ровном месте не в счёт.

[Алексей Кулик]

Андрей, ситуации бывают сильно разные - не стоит всех грести под одну гребенку.

[Андрей Бушман]

Андрей, ситуации бывают сильно разные - не стоит всех грести под одну гребенку.

Есть реальный пример, когда использование 0 будет полезным? Я считаю, что вешать на дверь табличку "Welcome, viruses!" - не самое разумное решение.

[Алексей Кулик]

В принципе есть. Идет отладка, загружается только что разработанный lsp из каталога, не являющегося доверенным. Или меню вместе с mnl для тестирования загружается из недоверенного каталога (смысла устанавливать новые значения на пару-тройку запусков лично я не вижу). Временно устанавливается secureload в 0, выполняется загрузка, значение переменной восстанавливается.

[Андрей Бушман]

Что мешает в доверительные каталоги добавить тестовый каталог, доступный для чтения\записи и сохранять отлаживаемые файлы в нём? Я именно так и делаю. Чем тебе кажется вариант с 0 лучше?

[Алексей Кулик]

Отсутствием необходимости дополнительного контроля (дублирование строк, совпадение каталогов и т.п.). Временное изменение secureload лично для меня значительно удобнее, быстрее и проще, чем вносить изменения в TRUSTEDPATHS и делать лишние проверки.

[Андрей Бушман]

Временно устанавливается secureload в 0, выполняется загрузка, значение переменной восстанавливается.

Всегда существует вероятность того, что ты забудешь это сделать:

1. в процессе работы твоего кода возникла необработанная ошибка до того, как ты восстановишь значение secureload, в результате чего твой код будет выполнен не полностью.
2. ты можешь просто забыть это сделать.
3. тебя могут отвлечь, например телефонным звонком и ты в "запарке" в последствии будешь "помнить", что восстановил, хотя это не так.
4. В процессе работы ты откроешь dwg (например из сетевого каталога), в каталоге которого за секунду до этого появилась зараза (благодаря другим пользователям)...
Т.о. использовать 0 в secureload при отладке - значит надеяться на "авось" которое, как правило, подводит в самый неподходящий момент.

Если же использовать обозначенный мною вариант с дополнительным доверительным каталогом, доступным для чтения\записи (локальным, либо размещённым на удалённой машинке, но открытым только тебе на чтение\запись), то вероятность поймать вирус существенно снижается (близка к нулю).

Я свои аргументы изложил. Если у тебя есть не менее веские аргументы в пользу использования secureload с 0, то я с интересом их выслушаю. Когда речь заходит о безопасности, то рассуждать о том, что на вкус и цвет все фломастеры разные - это большая ошибка. В вопросах безопасности должно превалировать логическое обоснование причины использования того или иного подхода.

[Александр Ривилис]

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

Интересно, а кроме Autodesk какие-то фирмы еще беспокоятся о безопасности своих CAD-систем? Мне всегда казалось, что есть некоторое разделение труда и бороться с вирусами должны антивирусы, а не CAD-системы.
Это я всё к тому, что при SECURELOAD == 0 соответствует поведению AutoCAD всех предыдущих версий до 2013 включительно (без SP1 или SP1.1).

[Андрей Бушман]

Отсутствием необходимости дополнительного контроля (дублирование строк, совпадение каталогов и т.п.). Временное изменение secureload лично для меня значительно удобнее, быстрее и проще, чем вносить изменения в TRUSTEDPATHS и делать лишние проверки.

Я не понял, о каком контроле и о каких проверках речь. Можешь пояснить? Переменную TRUSTEDPATHS я меняю один раз и более не трогаю. Что в этом сложного?

лично для меня значительно удобнее, быстрее и проще

Неправильный набор ключевых слов. Отсутствует главный аргумент: безопаснее.

[Андрей Бушман]

Интересно, а кроме Autodesk какие-то фирмы еще беспокоятся о безопасности своих CAD-систем?

Не нужно стрелки переводить. Мне не интересно, как с этим обстоят дела у др. CAD систем, поскольку мои пользователи используют AutoCAD. Деньги за AutoCAD (причём не малые) получает Autodesk, а не антивирусная компания или "компания другой CAD-системы".

Мне всегда казалось, что есть некоторое разделение труда и бороться с вирусами должны антивирусы, а не CAD-системы.

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

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

Это я всё к тому, что при SECURELOAD == 0 соответствует поведению AutoCAD всех предыдущих версий до 2013 включительно (без SP1 или SP1.1).

Я это прекрасно знаю и повторяю: оставлять такой вариант - это большая ошибка.

[Александр Ривилис]

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

Под определение вируса подходит на 100%: Компьютерный вирус

[Андрей Бушман]

Под определение вируса подходит на 100%: Компьютерный вирус

Отвлеклись от темы. Я так и не получил аргументированного ответа с примером того, где использовать 0 целесообразно (вариант о вкусах фломастеров из #9 меня не убеждает).

[Александр Ривилис]

Отвлеклись от темы. Я так и не получил аргументированного ответа с примером того, где использовать 0 целесообразно.

Ну вообще-то это всё обсуждение большой оффтоп, к теме статьи имеющий очень отдаленное отношение. Тем не менее у меня было несколько случаев (возможно это был баг AutoCAD 2014), когда .NET приложение грузилось только при SECURELOAD == 0. Добавление каталога с ним в доверенные не помогало.

[Андрей Бушман]

Тем не менее у меня было несколько случаев (возможно это был баг AutoCAD 2014), когда .NET приложение грузилось только при SECURELOAD == 0. Добавление каталога с ним в доверенные не помогало.

Поверю, когда сам увижу. Можете предоставить код? Кроме того, даже если бы это было и так - в ведро код, который способен работать только при SECURELOAD == 0.

[Александр Ривилис]

Можете предоставить код?

Приложение было не моё, так что код за неимением такового предоставить не могу. Точно знаю, что оно лезло в интернет, но каким образом SECURELOAD могло на это влиять - ума не приложу. Разве что на том конце выполнялся запуск JavaScript средствами .NET API и этот запуск блокировался, т.к. URL не был в TRUSTEDDOMAINS. Но туда я внести его бы и не мог, т.к. не знаю к какому сайту он обращается.

[Андрей Бушман]

Разве что на том конце выполнялся запуск JavaScript средствами .NET API и этот запуск блокировался, т.к. URL не был в TRUSTEDDOMAINS. Но туда я внести его бы и не мог, т.к. не знаю к какому сайту он обращается.

Тогда код этого разработчика нигде работать не будет, т.к. разумный человек ради этого не станет открывать брешь в системе защиты. Он должен был бы либо документировать необходимость предварительного изменения TRUSTEDDOMAINS, либо программно править TRUSTEDDOMAINS до обращения к удалённому ресурсу, либо править реестр из установщика (MSI), убедившись предварительно, что автокады не запущены. В любом случае это не является убедительным аргументом в пользу использования SECURELOAD == 0.

[Александр Ривилис]

Тогда код этого разработчика нигде рабоать не будет, т.к. разумный человек ради этого не станет открывать брешь в системе защиты.

Во всех предыдущих версиях "разумный человек" догадывался, что это приложение лезет в интернет (например, обновляет базу элементов - dwg-файлов), но понятия не имел куда именно она лезет. Ты же не отслеживаешь с какого именно сайта обновляются антивирусные базы KAV или Dr.Web или других антивирусов, с учетом того, что у них есть куча сайтов для этой цели.

Он должен был бы либо документировать необходимость изменения TRUSTEDDOMAINS

Немного потеоретизирую:
Приложение было написано и куплено под AutoCAD 2013 (без SP1), когда авторы понятия не имели что в SP1 им "перекроют дыхание". Они на себя не брали обязательств переделывать программу под изменившиеся AutoCAD'ы. Что делать покупателю-пользователю этой программы?
Всё не так просто.

[Андрей Бушман]

Приложение было написано и куплено под AutoCAD 2013 (без SP1), когда авторы понятия не имели что в SP1 им "перекроют дыхание". Они на себя не брали обязательств переделывать программу под изменившиеся AutoCAD'ы. Что делать покупателю-пользователю этой программы?
Всё не так просто.

SECURELOAD появилась в 2014-м.

[Александр Ривилис]

SECURELOAD появилась в 2014-м.

OK. Им перекрыли дыхание в AutoCAD 2014. Это принципиально что-то меняет? Как обычно авторы программы рассчитывали на её работоспособность в линейке из трёх версий, а покупатели выполнили обновление AutoCAD по подписке...

Так что я приветствую заложенную в AutoCAD возможность вернуться к старому поведению.

[Андрей Бушман]

OK. Им перекрыли дыхание в AutoCAD 2014. Это принципиально что-то меняет? Как обычно авторы программы рассчитывали на её работоспособность в линейке из трёх версий, а покупатели выполнили обновление AutoCAD по подписке...

Так что я приветствую заложенную в AutoCAD возможность вернуться к старому поведению.

Меняет. Безопасность всей системы в целом гораздо важнее работы отдельно взятого плагина (или даже n-го их количества). Говоря о "линейке из трёх версий" вы плавно перетекаете с .NET на ObjectARX. Если производитель ПО (ваш теоретический программист) заинтересован в продаже своего приложения, то он внесёт необходимые изменения в свой код, дабы идти в ногу с текущей моделью безопасности AutoCAD, тем более, что много усилий для этого не потребуется.

Так что я не приветствую наличие возможности открывать дыры вирусам в угоду отдельно взятого плагина.

[Алексей Кулик]

Андрей, уточняю: разговор шел о тестировании и разработке, а не о работе приложения (приложений) у клиента. Это раз. Второе: ты точно так же можешь забыть поменять TRUSTEDPATHS - и все, привет. Третье: для нормальной работы тебе придется парсить TRUSTEDPATHS на предмет "а нет ли там уже такого каталога; а нет ли там каталога-родителя с многоточием в конце". secureload в этом отношении проще и быстрее - а результат аналогичный. Четвертое: у меня в случае ошибки системные переменные возвращаются в свое начальное состояние - код для этого уже очень давно написан и постоянно используется. Тестирование и разработка вообще достаточно опасное занятие - и что теперь, не заниматься им?

[Андрей Бушман]

разговор шел о тестировании и разработке, а не о работе приложения (приложений) у клиента. Это раз.

Я тебе писал как раз о тестировании и разработке. Вариант с работой приложения я обсуждал с А.Н. Ривилисом.

Второе: ты точно так же можешь забыть поменять TRUSTEDPATHS - и все, привет.

А зачем мне его менять, да к тому же ещё и каждый раз? Один раз указываешь каталог и всё - он сохраняется в профиле AutoCAD. При ЛЮБОЙ отладке используешь этот профиль.

Третье: для нормальной работы тебе придется парсить TRUSTEDPATHS на предмет "а нет ли там уже такого каталога;

Что за велосипед??? В этом нет никакой необходимости, поэтому я никогда этого не делаю.

secureload в этом отношении проще и быстрее - а результат аналогичный.

Ты сравниваешь переключение значения secureload с каким-то нелепым набором действий, который вовсе не требуется. Наоборот, удобней один раз добавить запись в TRUSTEDPATHS (просто вручную, в Options), я имею в виду один раз ВООБЩЕ, а не в текущей сессии работы (на всякий случай уточняю).

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

Возможно. Однако не факт (к сожалению), что так же поступают и другие.

Тестирование и разработка вообще достаточно опасное занятие - и что теперь, не заниматься им?

Не опасно, если к этому подходить с умом (имхо). Не нужно сгущать краски. 

[Алексей Кулик]

Ты забываешь, что для lisp-приложений определить место, откуда они загружены, невозможно. Тебе не нравится решение с secureload? Ок, тебя никто не заставляет его использовать. Мне не нравится решение с trustedpaths - именно потому, что при работе приложения, предоставляемого клиенту, для корректной работы анализ trustedpaths приходится выполнять: откуда ты знаешь, первый раз или нет выполняется загрузка и запуск дополнения?
Предлагаю закончить спор, поскольку цель статьи была не "показать, как правильно", а "показать возможные пути".

[Андрей Бушман]

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

А этого и не нужно. Решение о разрешении\блокировки загрузки кода принимает AutoCAD, а не lisp.

Мне не нравится решение с trustedpaths - именно потому, что при работе приложения, предоставляемого клиенту, для корректной работы анализ trustedpaths приходится выполнять: откуда ты знаешь, первый раз или нет выполняется загрузка и запуск дополнения?

Каким боком это относится к теме? Если твой код запущен, значит нужная запись в trustedpaths присутствует (при условии, что SECURELOAD != 0).

Предлагаю закончить спор, поскольку цель статьи была не "показать, как правильно", а "показать возможные пути".

Ок, тем более, что мы с тобой, похоже, на разных языках говорим: я не понимаю твоей логики, а ты - моей.