Всем привет. Предвижу вопросы у большинства — а он разве не корпоративный?

Да, не корпоративный. Возможно, я связался с плохой компанией, но для меня пока ещё основной рабочий браузер — это Internet Explorer не выше 11 версии. Корпорация — организм большой, инертный. Менять софт — сплошные муки пользователям, головняк ИТ-службе, счастье интеграторам. Именно поэтому до сих пор на десктопах тут живёт винда, вплоть до XP, а периметры сетей зажаты в первую очередь бумагами с печатями, и потом уже межсетевыми экранами. Ну и основным «сдерживающим фактором» является обилие «легаси», приложений с ActiveX и безальтернативной поддержкой Internet Explorer в разметке.

Сразу скажу — чудес не бывает. ActiveX и поддержку тэгов/dom/багов IE в Firefox не прикрутить ну никоим образом. Даже заниматься этим не будем — всё равно в вашем плане импортозамещений, вероятно, есть строчка по выводу из эксплуатации устаревших приложений или их переработке. Второй нюанс — изолированность корпоративной сети вносит свои коррективы. Реестровый Яндекс.браузер без доступа в интернет практически бесполезен (даже вреден), как, впрочем, и Спутник, chromium. Chromium-gost видимо придётся использовать на некоторых рабочих местах, но не на всех. А вот старичок Firefox есть во всех отечественных дистрибутивах, и что самое важное, его всерьёз воспринимают производители коммерческого софта. Будем изучать его традиционно на RedHat-based отечественных дистрибутивах и, как обычно, сначала врукопашную.

Для начала определимся — что нам хочется:

1. Иметь возможность брать сертификаты со смарт-карты для аутентификации на некоторых ресурсах.
2. Иметь возможность подключаться к ресурсам с устаревшими криптографическими алгоритмами.
3. Доверять содержимому, подписанному внутренними корпоративными сертификатами.
4. Настройки производить втайне от пользователя и за минимальное время :)

▍ Подключаем смарт карточки

Смарт-карты или токены широко используются для аутентификации пользователей. Есть методы попроще, но первая аксиома безопасности гласит — удобство обратно пропорционально безопасности.

Устанавливаем на рабочую станцию необходимые пакеты поддержки смарт-карт. У меня это SafeNet Authentication Client и JaCarta PKCS #11 library. Пакеты поставили, теперь их необходимо прописать в браузере. Пользователь запускает браузер и заходит в «Настройки->Приватность и защита->Устройства защиты» и поочерёдно добавляет модули в формате pkcs11 из пакетов SAC и JaCarta.


На изображении показан уже установленный модуль для libeToken и добавление JaCarta

Вариант, конечно, рабочий, но мне не нравится — необходимо возить мышкой на каждом рабочем месте.

Следующий вариант вы обнаружите, если обратите внимание, что SAC будет числиться в security-девайсах у некоторых пользователей. Всё потому, что в rpm-пакете SafeNet Authentication Client в секции %postinstall имеется кусочек, который пробегается по домашним каталогам пользователей и через утилиту modutil добавляется в конфигурацию пользовательского firefox. На первый взгляд — довольно удобно, однако есть нюансы. На момент установки должен существовать каталог пользователя, в противном случае опять ручная установка.



Этот метод «полуавтоматический», и с некоторыми странностями — задаёт вопросы хоть и указан ключик -force. Если копнуть глубже, то пишет он всё в текстовый файл pkcs11.txt в профиле пользователя и его можно аккуратно редактировать через ansible/chef/puppet и т.д. при незапущенном браузере. Из минусов — нужно проходиться по профилям каждого пользователя, нужно выполнять при заведении нового пользователя.

Пока остановимся на этом варианте.

Если хотите прокачать своё понимание в реализации юниксовой криптографии, то рекомендую статью OpenSSL и Network Security Services (NSS) — две стороны одной медали, там и почерпнёте более глубокие знания об modultil.

▍ Добавляем устаревшие шифросьюты

Знаю — нехорошо. Однако уверен, что и у вас имеются информационные ресурсы не умеющие сильное шифрование. В Firefox возможность работы с устаревшими алгоритмами шифрования ещё имеется, хоть и спрятана подальше от пользователя.

Запускаем от юзера браузер и набираем в адресной строке about:config, принимаем на себя все риски и в строке поиска пишем tls. Всё, что надо поменять — выделено жирным на скриншоте:



Опять руками, опять мышонком. Сразу скажу, что firefox запишет эти настройки в текстовый файл ~/.mozilla/firifox/<имя профиля>/prefs.js, вот только править там что-либо руками не рекомендуется — об этом прямо написано в самом начале файла. Там же и подсказка — сделайте себе файл user.js и вставляйте в него всё что требуется. Сделали, всё работает — можно раскидывать этот файлик в профиль всем пользователям.

Однако не стоит спешить — есть system-wide вариант. Создаём /etc/firefox/pref/prefs.js, редактируем, добавляем ещё какие-нибудь ключики (например, аутентификацию kerberos) и всё автоматически появится у всех пользователей.

По настройкам about:config (да и не только) есть хорошая статья здесь на Хабре. Рекомендую немедленно ознакомиться.

▍ Добавляем корневые сертификаты

При попытке зайти на внутренние ресурсы получаем предупреждение об отсутствии к ним доверия. Всё понятно — пришло время добавить в браузер наши корпоративные самоподписанные корневые сертификаты.

Вручную — без проблем. Настройки->Приватность и защита->Просмотр сертификатов->Центры сертификации->Импортировать.... Сами представляете, как это долго и утомительно, да ещё на каждом рабочем месте.

Есть хороший (и правильный) вариант добавить их в систему оптом, причём не только для firefox. Мероприятие из двух пунктов:

1. Копируем все сертификаты в формате PEM в каталог /etc/pki/ca-trust/source/anchors/
2. От рута запускаем update-ca-trust

Проверяем: ROSA Linux сертификты в браузере появились, RED OS сертификаты в браузере не появились. Начнём разбираться.

Для начала смотрим в security devices на ROSA Linux — видно, что /etc/pki/ca-trust/source является слотом в модуле «Модуль встроенных корневых серт.», библиотека модуля /lib64/libnssckbi.so. Эта библиотека в конечном итоге является симлинком на /usr/lib64/pkcs11/p11-kit-trust.so и управляется через alternatives.

Заходим на RED OS и первым делом смотрим, на что нацелена alternatives libnssckbi.so.x86_64:



Всё честно.

Устройства безопасности в Firefox выглядят таким образом:



Сразу бросается в глаза — firefox собран таким образом, что он игнорирует системную libnssckbi.so, а имеет собственную /usr/lib64/firefox/libnssckbi.so, целиком и полностью набитую вражьими сертификатами!

Первая мысль — ln -sf /lib64/libnssckbi.so /usr/lib64/firefox/libnssckbi.so. Это сработает, но надо понимать, что при очередном обновлении firefox наш костыль с треском сломается.

Вторая попытка — добавить штатную libnssckbi вручную или через modutil, аналогично тому, как мы добавляли считыватели смарт-карт. Мне и в предыдущий раз это не особо понравилось, но одним устройством больше, одним меньше… Пока учтём как запасной вариант.

Третий подход. В устройствах защиты болтается странный «OS Client Cert Module» и с путём к модулю /usr/lib64/firefox/libosclientcerts.so. Какие сертификаты он предоставляет — непонятно, т.к. такого файлика в системе просто нет. Можно пихнуть вместо него симлинку на p11-kit-trust.so и будет работать, но я также считаю, что это неправильно — мало ли прилетит с очередным обновлением то, что изначально задумывал сборщик.

Четвёртая итерация — system-wide настройка через modutil. Теоретически всё лежит в /etc/pki/nssdb/, но и тут облом — мантэйнер RED OS позаботился, чтобы firefox туда не заглядывал.

Пятый вариант — лезем на support.mozilla.org и пытаемся найти что-нибудь подходящее (firefox не имеет никакой локальной документации, заглядывать в /usr/share/doc бесполезно). Там находим статью Настройка Firefox с помощью policies.json. Статья лаконичная, много недосказанного, хорошо хоть есть ссылка на README.md на гитхабе, откуда можно узнать место, где должен находиться файл policies.json в установленной системе, и какие политики существуют. Очень занятный документ.

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

Всё рассматривать не вижу смысла, приведу лишь простейший вариант для нашего случая /etc/firefox/policies/prefs.json:

{
    "policies": {
        "AppAutoUpdate": false,
        "DisableAppUpdate": true,
        "DisableFeedbackCommands": true,
        "DisablePocket": true,
        "DisableTelemetry": true,
        "DNSOverHTTPS": {
            "Enabled": false,
            "Locked": true
        },
        "EncryptedMediaExtensions": {
            "Enabled": true,
            "Locked": false
        },
        "FirefoxHome": {
            "Search": false,
            "TopSites": true,
            "Highlights": false,
            "Pocket": false,
            "Snippets": false,
            "Locked": false
        },
        "HardwareAcceleration": true,
        "Homepage": {
            "URL": "file:///usr/share/doc/HTML/index.html",
            "Locked": false,
            "StartPage": "homepage"
        },
        "NoDefaultBookmarks": true,
        "OverrideFirstRunPage": "",
        "OverridePostUpdatePage": "",
        "PromptForDownloadLocation": true,
        "ShowHomeButton": true,
        "SecurityDevices": {
            "p11-kit-trust": "/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so",
            "libeToken": "/usr/lib64/libjcPKCS11-2.so",
            "JaCarta": "/usr/lib64/pkcs11/libjcpkcs11-2.so"
        }
    }
}

В данном файле пока самое интересное это ключик «SecurityDevices», т.к. он полностью избавляет нас от проблем раздела 1 и 3 статьи. Складываем этот файл на каждое рабочее место в процессе инсталляции и всё. Не забываем только кидать свежие сертификаты в /etc/pki/ca-trust/source/anchors и запускать update-ca-trust.

А тот, кто прочитает README.md полностью или даже выборочно, избавится от ведения отдельного prefs.js для старых шифросьютов и попутно настроит аутентификацию в соответствии с корпоративными требованиями. Намеренно не стал вставлять в пример конфига — домашнее задание :)

▍ Финал

These policies are in active development and so might contain changes that do not work with current versions of Firefox.

Первая строчка файла README.md вроде как намекает нам, что нет ничего вечного и что всё может внезапно измениться в будущем. Но всё равно, на текущий момент я считаю данный метод наиболее правильным и удобным.

Хочу обратить внимание, что начиналось всё с тривиальных задач по ручному подключению смарт-карт и добавлению корневых сертификатов к firefox, а в конце нашлось очень мощное средство, позволяющее свести рутинную ручную настройку пользовательского браузера на каждом рабочем месте к простому распространению файла политик. Обычно так бывает всегда, главное — не останавливаться на первых положительных результатах, а копать глубже.

Telegram-канал с полезностями и уютный чат