В отличие от других версий ставится, действительно, лучше, но...
Я прогонял KES на двух машинах - сначала пробовал на виртуальной, затем уже на реальной
На виртуальной всё встало ровно. На реальной работает всё, кроме постоянной защиты файлов (file monitoring). В описании ошибки причиной указана ошибка драйвера перехватчика.
Никто не знает, что за зверь, и как его приручить?
Тестировал и на виртуальных машинах, и на реальном железе. Проблем с постоянной защитой не заметил. На реальном железе наблюдаю проблемы с остановкой сервиса kesl-supervisor при выключении компьютера.
Ядро при загрузке поменяйте на стандарт, так как вы наверняка устанавливали билютень безопасности. Проверте, что ядро грузится стандартное, и в путь. Проверено на 1.5 se
Ядро при загрузке поменяйте на стандарт, так как вы наверняка устанавливали билютень безопасности. Проверте, что ядро грузится стандартное, и в путь. Проверено на 1.5 se
Судя по всему проблема кроется в подсистеме parsec, которую приводит в состояние дедлока механизм fanotify, используемый в KESL 10. По существу получается, что из-за невозможности корректного завершения работы процесса kesl во время принудительного завершения всех незавершенных процессов и происходит эта мертвая блокировка:
Решений есть два: первое и самое простое, но не самое правильное - создать файл /etc/init.d/.legacy-bootordering для переключения на legacy-режим запуска скриптов, при котором по моему опыту скрипт остановки KESL отрабатывает штатно.
Второе решение: воспользоваться пропатченными скриптами KESL из приложенных архивов и после перезаписи файлов из них выполнить команду update-rc.d kesl-supervisor disable и потом update-rc.d kesl-supervisor enable для обновления файлов-описателей зависимостей запуска в /etc/init.d
После этого перезагрузившись (возможно принудительно), на следующей перезагрузке/выключении все должно стать нормально. Зависания должны прекратиться.
Если речь идет о 6421, то с ней наблюдаются точно те же самые эффекты, т.к. судя по скриптам ничего в них не изменилось.
Я говорю про остановку работы системы, а не про запуск.
Орлов много разных, если Вы о свежей версии, то я практически не сомневаюсь, что так и есть, все работает штатно. Но в заголовке темы написано "Смоленск 1.5" и поэтому причем здесь свежий Орел?
Смоленском к сожалению не располагаю. Где то в организации есть 1.5, но мимо меня. Считаю необходимым зондировать почву для обновления Смоленска до актуальной версии. Скорее всего в старые версии как обычно пойдут только обновления безопасности. А весь новый функционал только в новые.
Сравнил ее с общей сборкой версии 6421. Оптимизация под Астру заключается в выпиливании исходников модуля ядра, добавлении предсобранного модуля ядра для версии ядра 3.16.0-16-(generic||pax) и запуске процесса мониторинга файлов через exеcaps "${WDSERVER_BIN}" ${WDSERVER_FLAGS} -e /usr/sbin/execaps -c 0x300 -- "${PRODUCT_BIN}", т.е. с capability PARSEC PARSEC_CAP_PRIV_SOCK и PARSEC_CAP_READSEARCH для игнорирования мандатных меток при доступе к файлам на чтение, что логично и необходимо. В остальном все то же самое в отношении описанных мною ранее проблем в скриптах.
Небольшое обновление, может быть кому-нибудь будет полезно: в приложенном архиве доработанные файлы скриптов для kesl-astra_10.1.1-6421_amd64 и версий для простых Linux'ов.
Кто-нибудь знает как её заставить работать в режиме замкнутой программной среды в Смоленске? Пробовал и 6024, и 6421. Ставил из папки Astra официального диска. При запуске выдаёт что файлы не подписаны.
В формуляре написано что в работает и в обычном режиме, и в ЗПС, как в 1.5, так и в 1.6. Но больше никакой информации о ЗПС в документации или форумах Каспера нет.
Спасибо за помощь. С "Kaspersky public key" запустилась 6024 в ЗПС, 6421 пока не пробовал.
Не понимаю что им мешало положить публичный ключ на официальный диск.