Services Policy: различия между версиями

Материал из ALT Linux Wiki
м Services» переименована в «ServicesPolicy»: +keyword в название)
(+DraftPolicy)
Строка 1: Строка 1:
[[Category:Policy]]
{{DraftPolicy
{{MovedFromFreesourceInfo|AltLinux/Policy/Services}}
|responsible=...
}}


== Сервисы ==
== Сервисы ==
=== О чём речь ===
=== О чём речь ===
Предлагается к обсуждению и доработке драфт полиси по упаковке программ, которые для возможности использования должны принимать сетевые подключения (в силу того, что это всегда может быть связано с ненулевым риском атаки на уязвимое место).
Предлагается к обсуждению и доработке драфт полиси по упаковке программ, которые для возможности использования должны принимать сетевые подключения (в силу того, что это всегда может быть связано с ненулевым риском атаки на уязвимое место).


С учётом того, что забыть выключенным нужный сервис (разве что кроме sshd) несколько сложнее, чем забыть включенным ненужный -- лучше по возможности и разумности держать в пакетах умолчание "выключен". Аналогично по части доступа -- рассмотрите уместность такового по умолчанию только с петлевого интерфейса (loopback, lo) 127.0.0.1 или изменением штатного адреса привязки (bind, listen) сервиса с <tt>0.0.0.0</tt> на <tt>127.0.0.1</tt>, либо аналогичным ограничением средствами сервиса (менее надёжно, поскольку уязвимость иногда может быть в коде, который успеет выполниться до контроля доступа).
С учётом того, что забыть выключенным нужный сервис (разве что кроме sshd) несколько сложнее, чем забыть включенным ненужный — лучше по возможности и разумности держать в пакетах умолчание «выключен». Аналогично по части доступа — рассмотрите уместность такового по умолчанию только с петлевого интерфейса (loopback, lo) 127.0.0.1 или изменением штатного адреса привязки (bind, listen) сервиса с <tt>0.0.0.0</tt> на <tt>127.0.0.1</tt>, либо аналогичным ограничением средствами сервиса (менее надёжно, поскольку уязвимость иногда может быть в коде, который успеет выполниться до контроля доступа).


В случае неочевидных действий, необходимых для конфигурирования сервиса в рабочем режиме, следует описать их хотя бы парой строк в файле README.ALT, уложенном в каталог с документацией пакета; возможно и упоминание в %description вида
В случае неочевидных действий, необходимых для конфигурирования сервиса в рабочем режиме, следует описать их хотя бы парой строк в файле README.ALT, уложенном в каталог с документацией пакета; возможно и упоминание в %description вида
Строка 20: Строка 22:


=== SysV initscripts ===
=== SysV initscripts ===
Для сервисов, запускаемых посредством инитскриптов в <tt>%_initdir</tt> (<tt>/etc/rc.d/init.d/</tt>), образцом является <tt>/etc/rc.d/init.d/template</tt>, а рекомендуемым видом строчки chkconfig -- подобный:
Для сервисов, запускаемых посредством инитскриптов в <tt>%_initdir</tt> (<tt>/etc/rc.d/init.d/</tt>), образцом является <tt>/etc/rc.d/init.d/template</tt>, а рекомендуемым видом строчки chkconfig — подобный:
<pre># chkconfig: - 90 10</pre>
<pre># chkconfig: - 90 10</pre>


Первый аргумент либо задаёт список уровней исполнения (runlevels), в которых данный сервис будет запущен автоматически (например, <tt>345</tt>), либо является прочерком (<tt>-</tt>), что указывает на состояние "выключен по умолчанию".
Первый аргумент либо задаёт список уровней исполнения (runlevels), в которых данный сервис будет запущен автоматически (например, <tt>345</tt>), либо является прочерком (<tt>-</tt>), что указывает на состояние «выключен по умолчанию».


=== xinetd based ===
=== xinetd based ===

Версия от 18:05, 10 сентября 2008

Stub.png
Черновик политики Sisyphus
Автор(ы) — ...


Сервисы

О чём речь

Предлагается к обсуждению и доработке драфт полиси по упаковке программ, которые для возможности использования должны принимать сетевые подключения (в силу того, что это всегда может быть связано с ненулевым риском атаки на уязвимое место).

С учётом того, что забыть выключенным нужный сервис (разве что кроме sshd) несколько сложнее, чем забыть включенным ненужный — лучше по возможности и разумности держать в пакетах умолчание «выключен». Аналогично по части доступа — рассмотрите уместность такового по умолчанию только с петлевого интерфейса (loopback, lo) 127.0.0.1 или изменением штатного адреса привязки (bind, listen) сервиса с 0.0.0.0 на 127.0.0.1, либо аналогичным ограничением средствами сервиса (менее надёжно, поскольку уязвимость иногда может быть в коде, который успеет выполниться до контроля доступа).

В случае неочевидных действий, необходимых для конфигурирования сервиса в рабочем режиме, следует описать их хотя бы парой строк в файле README.ALT, уложенном в каталог с документацией пакета; возможно и упоминание в %description вида

The service is off by default.

или

The service will only accept connections from 127.0.0.1 by default,
see README.ALT and configure it as needed.

в случаях, когда предвидятся проблемы у разворачивающих сервис системных администраторов.

Внося такие изменения, следует и отметить их в changelog (хотя при обновлении уже установленного пакета, предоставляющего сконфигурированный и включенный сервис, они не должны иметь действия).

Если эта практика будет принята, то следует упомянуть о ней в официальной документации на страничке с кратким сборником отличий дистрибутива.

SysV initscripts

Для сервисов, запускаемых посредством инитскриптов в %_initdir (/etc/rc.d/init.d/), образцом является /etc/rc.d/init.d/template, а рекомендуемым видом строчки chkconfig — подобный:

# chkconfig: - 90 10

Первый аргумент либо задаёт список уровней исполнения (runlevels), в которых данный сервис будет запущен автоматически (например, 345), либо является прочерком (-), что указывает на состояние «выключен по умолчанию».

xinetd based

Для сервисов, стартующих из-под xinetd, рекомендуемым является включение в файл конфигурации, укладываемый в /etc/xinetd.d/, строчки

disable = yes

и по вкусу (для достаточно недоверенных сервисов?) --

only_from = 127.0.0.1

Ссылки