''Sandbox'' - это термин, используемый при обеспечении безопасности. Он имеет два значения:

• Процесс, помещённый внутрь некоторых виртуальных стен, которые предназначены для того, чтобы предотвратить взлом всей системы в результате взлома этого конкретного процесса.

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

  Стеной может служить, например, идентификатор пользователя. Вот определение, даваемое на страницах справочной системы security(7) и named(8).

  Рассмотрим, например, службу ntalk (смотрите /etc/inetd.conf). Раньше эта служба запускалась с идентификатором пользователя 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).

Для исходящих запросов BIND использует случайно выбираемый порт с большим номером. Если для исходящих запросов вы хотите использовать порт с номером 53 для работы за межсетевым экраном либо просто для собственного спокойствия, то можете попробовать настроить файл /etc/namedb/named.conf следующим образом:

options {
        query-source address * port 53;
};

Можете заменить символ * некоторым IP-адресом, если хотите настроить все еще жестче.

Кстати, поздравляем. Прекрасно, что вы читаете вывод команды sockstat(1) и обращаете внимание на аномалии!

Последние версии 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.

В целях обеспечения безопасности suidperl по умолчанию устанавливается без suid-бита. Системный администратор может включить использование suid-бита следующей командой.

# chmod u+s /usr/bin/suidperl

Если вы хотите, чтобы suid-бит для suidperl было установлен во время обновления из исходных текстов, отредактируйте /etc/make.conf, добавив ENABLE_SUIDPERL=true перед запуском make buildworld.