Customizing Firefox Using policies.json
This article is intended for IT administrators who wish to set up Firefox on the computers within their organization.
Policy support can be implemented using a JSON file called policies.json. Unlike controlling Firefox with using Group Policy, the policies.json is cross-platform compatible, making it preferred method for enterprise environments that have workstations running various operating systems.
To implement this policy support, a policies.json file needs to be created. This file goes into a directory called distribution within the Firefox installation directory. This directory is not usually included by default, so you may need to manually create this directory.
The policies.json file looks like this:
In this example, we are setting the BlockAboutConfig policy to true , which means that the user will not have access to the about:config page.
The latest information about our policies is available in the README on our GitHub repository.
NOTE: The above method will not work if Firefox is already being managed using Group Policy.
These fine people helped write this article:
Volunteer
Grow and share your expertise with others. Answer questions and improve our knowledge base.
Настройка Firefox с помощью policies.json
Поддержка политики может быть реализована с помощью JSON-файла policies.json. В отличие от контроля Firefox с использованием групповой политики policies.json обладает кроссплатформенной совместимостью, что делает его предпочтительным методом для корпоративных окружений, в которых присутствуют рабочие станции, на которых запущены различные операционные системы.
Чтобы реализовать поддержку этой политики, необходимо создать файл policies.json . Этот файл необходимо расположить в директории с названием distribution в директории установки Firefox. Эта директория отсутствует по умолчанию, поэтому вам может потребоваться создать её вручную.
Файл policies.json выглядит примерно так:
В этом примере мы настроили политику BlockAboutConfig в true , что означает, что пользователи не будут иметь доступ к странице about:config .
Актуальная информация о наших политиках доступна в файле README в нашем GitHub-репозитории.
ПРИМЕЧАНИЕ: Описанный выше метод не будет работать, если Firefox уже управляется с помощью групповой политики.
Эти прекрасные люди помогли написать эту статью:
Станьте волонтёром
Растите и делитесь опытом с другими. Отвечайте на вопросы и улучшайте нашу базу знаний.
Делаем firefox корпоративным браузером
Всем привет. Предвижу вопросы у большинства — а он разве не корпоративный?
Да, не корпоративный. Возможно, я связался с плохой компанией, но для меня пока ещё основной рабочий браузер — это Internet Explorer не выше 11 версии. Корпорация — организм большой, инертный. Менять софт — сплошные муки пользователям, головняк ИТ-службе, счастье интеграторам. Именно поэтому до сих пор на десктопах тут живёт винда, вплоть до XP, а периметры сетей зажаты в первую очередь бумагами с печатями, и потом уже межсетевыми экранами. Ну и основным «сдерживающим фактором» является обилие «легаси», приложений с ActiveX и безальтернативной поддержкой Internet Explorer в разметке.
Сразу скажу — чудес не бывает. ActiveX и поддержку тэгов/dom/багов IE в Firefox не прикрутить ну никоим образом. Даже заниматься этим не будем — всё равно в вашем плане импортозамещений, вероятно, есть строчка по выводу из эксплуатации устаревших приложений или их переработке. Второй нюанс — изолированность корпоративной сети вносит свои коррективы. Реестровый Яндекс.браузер без доступа в интернет практически бесполезен (даже вреден), как, впрочем, и Спутник, chromium. Chromium-gost видимо придётся использовать на некоторых рабочих местах, но не на всех. А вот старичок Firefox есть во всех отечественных дистрибутивах, и что самое важное, его всерьёз воспринимают производители коммерческого софта. Будем изучать его традиционно на RedHat-based отечественных дистрибутивах и, как обычно, сначала врукопашную.
Для начала определимся — что нам хочется:
- Иметь возможность брать сертификаты со смарт-карты для аутентификации на некоторых ресурсах.
- Иметь возможность подключаться к ресурсам с устаревшими криптографическими алгоритмами.
- Доверять содержимому, подписанному внутренними корпоративными сертификатами.
- Настройки производить втайне от пользователя и за минимальное время 🙂
▍ Подключаем смарт карточки
Смарт-карты или токены широко используются для аутентификации пользователей. Есть методы попроще, но первая аксиома безопасности гласит — удобство обратно пропорционально безопасности.
Устанавливаем на рабочую станцию необходимые пакеты поддержки смарт-карт. У меня это 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. Мероприятие из двух пунктов:
- Копируем все сертификаты в формате PEM в каталог /etc/pki/ca-trust/source/anchors/
- От рута запускаем update-ca-trust
Для начала смотрим в 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, а в конце нашлось очень мощное средство, позволяющее свести рутинную ручную настройку пользовательского браузера на каждом рабочем месте к простому распространению файла политик. Обычно так бывает всегда, главное — не останавливаться на первых положительных результатах, а копать глубже.
