''Sandbox'' - это термин, используемый при обеспечении безопасности. Он имеет два значения:
Процесс, помещённый внутрь некоторых виртуальных стен, которые предназначены для того, чтобы предотвратить взлом всей системы в результате взлома этого конкретного процесса.
Говорится, что процесс может ''играть'' в границах этих стен. Что бы этот процесс ни делал, он эти стены разрушить не может, поэтому вам не нужен его особый аудит, чтобы с уверенностью сказать, насколько его работа безопасна для системы.
Стеной может служить, например, идентификатор пользователя. Вот определение, даваемое на страницах справочной системы security(7) и named(8).
Рассмотрим, например, службу ntalk (смотрите inetd(8)). Раньше эта служба запускалась с идентификатором пользователя root, а сейчас — tty. Пользователь tty — это та песочница, которая осложняет взлом системы через ntalk посредством использования этого идентификатора пользователя.
Процесс, помещённый внутрь симулируемой машины. Это даёт больший уровень безопасности. В общем это означает, что некто, взломавший процесс, может думать, что может сломать и систему в целом, однако фактически может сломать только симулятор этой машины и не может модифицировать никаких реальных данных.
Самым распространённым способом достигнуть такого результата является построение имитирующего окружения в каталоге и затем запуск процессов в этом каталоге через chroot (т.е. задав этот каталог в качестве / для этого процесса, а не реальный / всей системы).
Другим часто используемым методом является монтирование низлежащей файловой системы в режиме "только для чтения" и затем создание уровня файловой системы поверх неё, что даёт процессу видимость доступа по записи на ту файловую систему. Процесс будет полагать, что может записывать в те файлы, но это будет единственный процесс, который увидит результат — другие процессы не будут этого делать ни в коем случае.
Попытка сделать такой тип песочницы настолько прозрачна, что пользователь (или взломщик) даже не поймёт, что он в ней находится.
В UNIX® реализованы два типа ''песочниц''. Один на уровне процесса, и один на уровне идентификаторов пользователей.
Каждый процесс в UNIX полностью защищён от других процессов. Никакой процесс не может модифицировать адресное пространство другого процесса. Это отличается от Windows®, где процесс может легко записать что-либо в адресное пространство другого процесса, что приводит к аварийным ситуациям.
В UNIX каждым процессом владеет некоторый идентификатор пользователя. Если этот пользователь не root, он ограждает процесс от других, владельцами которых являются другие пользователи. Этот идентификатор используется также для защиты данных на диске.
Уровень защиты является механизмом обеспечения безопасности, реализованным в ядре. В общем, когда уровень защиты больше нуля, ядро ограничивает выполнение некоторых операций; даже администратору (то есть пользователю root) запрещается их выполнять. На момент написания этого текста механизм уровня защиты может, кроме всего прочего, ограничивать возможности по:
снятию некоторых флагов с файлов, таких, как schg (системный флаг неизменяемости),
записи в память ядра через устройства /dev/mem и /dev/kmem,
загрузке модулей ядра и
изменению правил сетевого экрана.
Для выяснения состояния уровня защиты в работающей системе просто выполните следующую команду:
# sysctl kern.securelevel
Результат будет содержать название sysctl(8)-переменной
(в нашем случае это kern.securelevel
) и число.
Последнее и является текущим значением уровня защиты. Если оно положительно (то
есть больше нуля), то по крайней мере некоторые из защит этого механизма
включены.
Вы не можете понизить уровень защиты работающей системы; возможность сделать это
противоречит назначению этого механизма. Если вам нужно выполнить работу, которая
требует не положительный уровень защиты (к примеру, выполнение installworld или смена даты), вам потребуется изменить
настройки уровня защиты системы в файле /etc/rc.conf (вам
нужно обратить внимание на переменные kern_securelevel
и kern_securelevel_enable
) и перезагрузить
систему.
Более подробная информация об уровнях защиты и о том, какие специфические действия выполняют все уровни, может быть найдена на справочных страницах о init(8).
Внимание: Уровень защиты не является панацеей; в нём есть много недостатков. Зачастую он даёт обманчивое чувство безопасности.
Одной из самых больших проблем является то, что для его эффективной работы все файлы, используемые в процессе загрузки, должны быть защищены. Если атакующий сможет заставить систему выполнять свой код до установки уровня защиты (что происходит достаточно поздно во время процесса загрузки, так как некоторые вещи, выполняемые системой в это время, не могут быть сделаны при повышенном уровне защиты), то эта защита может быть отключена. Хотя такая задача по защите всех файлов, используемых в процессе загрузки, технически вполне осуществима, если это будет сделано, то поддержка системы станет кошмаром, так как для изменения конфигурационного файла придётся останавливать систему, переводя её по крайней мере в однопользовательский режим.
Это обстоятельство, а также ряд других, часто обсуждаются в списках рассылки, в частности, во Список рассылки FreeBSD, посвящённый информационной безопасности. Пожалуйста, поищите в архивах более подробное обсуждение. Некоторые надеются, что механизм уровней защиты вскоре отомрёт, а на его смену придёт более гибкий механизм, но пока всё это туманно.
Считайте себя предупреждёнными.
Для исходящих запросов BIND использует случайно выбираемый порт с большим номером. В последних версиях при каждом запросе выбирается новый случайный порт UDP. Это может вызвать проблемы в некоторых сетевых конфигурациях, особенно если фаервол блокирует входящие UDP пакеты на определенных портах. Если вы хотите обеспечить хождение пакетов через фаервол, то вы можете попробовать параметры avoid-v4-udp-ports и avoid-v6-udp-ports, чтобы предотвратить случайный выбор номеров портов, пересекающихся с блокируемым диапазоном.
Внимание: Если в /etc/namedb/named.conf указан номер порта (такой как 53) в параметре query-source или query-source-v6, то случайный выбор порта использоваться не будет. Настоятельно рекомендуется, чтобы эти параметры не использовались для указания фиксированных номеров порта.
Кстати, поздравляем. Прекрасно, что вы читаете вывод команды sockstat(1) и обращаете внимание на аномалии!
13.4. Даемон sendmail ждёт соединений как на стандартном порту 25, так и на порту 587! Что происходит?
Последние версии sendmail поддерживают механизм посылки почты, который работает по порту 587. Эта возможность пока широко не используется, но ее популярность растет.
Не волнуйтесь, toor является ''альтернативным'' административным пользователем (toor - это root, записанный задом наперед). Раньше он создавался при установке командного интерпретатора bash(1), однако теперь он создается по умолчанию. Его предполагается использовать с нестандартным командным интерпретатором, так чтобы вам не нужно было менять используемый по умолчанию командный процессор для пользователя root. Это важно, так как оболочки, не являющиеся частью дистрибутива системы (например, командный процессор, устанавливаемый из портов или пакаджей), скорее всего, устанавливаются в каталог /usr/local/bin, который по умолчанию располагается в другой файловой системе. Если командный процессор для пользователя root располагается в /usr/local/bin, и /usr (или другая файловая система, содержащая /usr/local/bin) по какой-либо причине не смонтирована, то root не сможет войти в систему для исправления этой проблемы (хотя если вы перезагрузите систему в однопользовательский режим, вы сможете указать командный процессор).
Некоторые используют toor для выполнения повседневных административных работ с нестандартным командным процессором, оставляя root со стандартной оболочкой для работы в однопользовательском режиме или выполнения аварийных работ. По умолчанию вы не сможете войти в систему как пользователь toor, потому что у него нет пароля, так что, если вы хотите его использовать, зарегистрируйтесь в системе как root и задайте пароль для пользователя toor.
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.