[devel] I: base utilities for network analisys are now chrooted

[devel] I: base utilities for network analisys are now chrooted

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

Greetings!

По окончании сегодняшней синхронизации в Сизифе основные средства
анализа сети chroot'изированы.

Это значит, что еще до начала работы с пакетами из сети процесс будет
находится в chroot'е (/var/resolv) с правами пользователя (даже если был
запущен root'ом).

Изменениям подверглись следующие пакеты:
chrooted-resolv
iputils
ngrep
tcpdump
traceroute

Новую технологию защиты поддерживают следующие программы:
/bin/ping
/usr/sbin/arping
/usr/sbin/clockdiff
/usr/sbin/ping6
/usr/sbin/tracepath
/usr/sbin/tracepath6
/usr/sbin/traceroute6
/usr/sbin/traceroute
/usr/sbin/tcpdump
/usr/bin/ngrep

Насколько мне известно, ущерба функциональности ни одной из этих программ
не нанесено.

P.S. Господа администраторы, по окончании внесения изменения в любой из
     нижеперечисленных файлов, не забудьте запустить команду
     "/usr/sbin/update_chrooted conf"
     Список файлов:
     /etc/{localtime,hosts,services,{host,nsswitch,resolv}.conf}


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.com/
Fandra Project      http://www.fandra.org/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[devel] README.ALT wanted (was: I: base utilities for network analisys are now chrooted)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

On Fri, Aug 10, 2012 at 12:38:38PM +0400, Volkov Serge wrote:
> > P.S. Господа администраторы, по окончании внесения изменения в любой из
> >      нижеперечисленных файлов, не забудьте запустить команду
> >      "/usr/sbin/update_chrooted conf"
> Насколько я понимаю это все попадет в Мастер, тогда надо
> добавить эту информацию как README.FIRST иначе могут возникнуть
> лишние вопросы.
Угу.  Вот не помню, сказано ли в admin manual, что в xinetd.*
есть не только индивидуальные DISABLE=YES, но и "общее"
ONLY_FROM=127.0.0.1 -- человек тут утверждал, что потерял две
ночи из-за этого (плюс наводки от кривого PXE в eepro100 8-)) --
после решения проблемы и разъяснения ограничился замечанием, что
"в openbsd _таких_ параноиков не водится" 8-))

И вообще хорошо бы "альтовости" повыносить в отдельный checklist
(/README.ALT), дабы людям было легче портироваться.  Примерный
список Q&A -- думаю, по сервисам и "чего не дают руту".

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] README.ALT wanted (was: I: base utilities for network analisys are now chrooted)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

On Wed, Apr 10, 2002 at 09:58:43PM +0300, Michael Shigorin wrote:
> > > P.S. Господа администраторы, по окончании внесения изменения в любой из
> > >      нижеперечисленных файлов, не забудьте запустить команду
> > >      "/usr/sbin/update_chrooted conf"
> > Насколько я понимаю это все попадет в Мастер, тогда надо
> > добавить эту информацию как README.FIRST иначе могут возникнуть
> > лишние вопросы.
> Угу.  Вот не помню, сказано ли в admin manual, что в xinetd.*
> есть не только индивидуальные DISABLE=YES, но и "общее"
> ONLY_FROM=127.0.0.1 -- человек тут утверждал, что потерял две
> ночи из-за этого (плюс наводки от кривого PXE в eepro100 8-)) --
> после решения проблемы и разъяснения ограничился замечанием, что
> "в openbsd _таких_ параноиков не водится" 8-))
> 
> И вообще хорошо бы "альтовости" повыносить в отдельный checklist
> (/README.ALT), дабы людям было легче портироваться.  Примерный
> список Q&A -- думаю, по сервисам и "чего не дают руту".

Ok, давайте попробуем "вспомнить все", пока еще не поздно.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.com/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[devel] Re: README.ALT wanted (was: I: base utilities for network analisys are now chrooted)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 3057 bytes --]

On Thu, Apr 11, 2002 at 11:18:28AM +0400, Dmitry V. Levin wrote:
> > Угу.  Вот не помню, сказано ли в admin manual, что в xinetd.*
> > есть не только индивидуальные DISABLE=YES, но и "общее"
> > ONLY_FROM=127.0.0.1 -- человек тут утверждал, что потерял две
Кстати, он обратил внимание еще на одну багу: заведению подлежал
tftpd и он не работал на сеть до первого обращения с локалхоста,
после чего (благодаря wait = yes) работал и с внешней сетью.

Наверное, имеет смысл прошерстить xinetd-enabled пакеты на эту
тему...

> > И вообще хорошо бы "альтовости" повыносить в отдельный checklist
> > (/README.ALT), дабы людям было легче портироваться.  Примерный
> > список Q&A -- думаю, по сервисам и "чего не дают руту".
> Ok, давайте попробуем "вспомнить все", пока еще не поздно.
Попробую.

Часть I.  root squashed

Q: почему руту не ходит почта?

A: в силу того, что читать почту под этим аккаунтом крайне не
рекомендуется (вариант -- запрещено по политике безопасности
дистрибутива), при инсталяции создается почтовый алиас,
переправляющий почту на первого зарегистрированного пользователя
(подразумевается, что это тот же человек, который устанавливал
систему).

Если это не устраивает (нужен другой пользователь), загляните в
/etc/postfix/aliases (после правки необходимо запустить от имени
root команду postalias).

Q: почему руту не дают собирать RPM? Выдается ошибка:
"rpmb: сборка пакетов запрещена для привилегированного пользователя"

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

Для дополнительной информации обратитесь к содержимому
/usr/share/doc/rpm-*/README.ALT .

Q: у рута сломана локаль!

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

Крайне не рекомендуется выполнять ежедневную работу от имени root
-- а для администрирования должно хватить sudo и нормального
локализованного пользовательского аккаунта.

Если же вопрос стоит очень остро -- произведите поиск строки LANG
в файлах в домашнем каталоге администратора.
   
Часть II.  notwork troubles

Q: почему после установки сервера и его активации (в ntsysv,
DrakConf, /etc/xinetd.d/*) он недоступен из сети?

A1: по умолчанию в ALT Linux xinetd сконфигурирован с опцией
only_from = 127.0.0.1, позволяющей доступ к сервисам,
запускающимся из-под xinetd, только с локальной машины.

Для обеспечения доступа из сети отредактируйте или
закомментируйте эту строку в /etc/xinetd.conf; в последнем случае
настоятельно рекомендуем ввести ограничения по необходимости в
индивидуальные файлы в каталоге /etc/xinetd.d/ .

A2: если проблема не в этом -- обратите внимание на настройки
файрвола (service iptables status или service ipchains status).

A3: проверьте содержимое файлов /etc/hosts.allow и /etc/hosts.deny
(XXX есть какой-то TFM на эту тему?)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] Re: README.ALT wanted (was: I: base utilities for network analisys are now chrooted)

[cornet]

Michael Shigorin wrote:
> 
> On Thu, Apr 11, 2002 at 11:18:28AM +0400, Dmitry V. Levin wrote:
> > > Угу.  Вот не помню, сказано ли в admin manual, что в xinetd.*
> > > есть не только индивидуальные DISABLE=YES, но и "общее"
> > > ONLY_FROM=127.0.0.1 -- человек тут утверждал, что потерял две
> Кстати, он обратил внимание еще на одну багу: заведению подлежал
> tftpd и он не работал на сеть до первого обращения с локалхоста,
> после чего (благодаря wait = yes) работал и с внешней сетью.
> 
> Наверное, имеет смысл прошерстить xinetd-enabled пакеты на эту
> тему...
> 
> > > И вообще хорошо бы "альтовости" повыносить в отдельный checklist
> > > (/README.ALT), дабы людям было легче портироваться.  Примерный
> > > список Q&A -- думаю, по сервисам и "чего не дают руту".
> > Ok, давайте попробуем "вспомнить все", пока еще не поздно.
> Попробую.
> 
> Часть I.  root squashed
> 
> Q: почему руту не ходит почта?
> 
> A: в силу того, что читать почту под этим аккаунтом крайне не
> рекомендуется (вариант -- запрещено по политике безопасности
> дистрибутива), при инсталяции создается почтовый алиас,
> переправляющий почту на первого зарегистрированного пользователя
> (подразумевается, что это тот же человек, который устанавливал
> систему).
> 
> Если это не устраивает (нужен другой пользователь), загляните в
> /etc/postfix/aliases (после правки необходимо запустить от имени
> root команду postalias).
> 
> Q: почему руту не дают собирать RPM? Выдается ошибка:
> "rpmb: сборка пакетов запрещена для привилегированного пользователя"
> 
> A: сборка пакетов привелегированным пользователем является
> потенциально небезопасной (плюс к тому, что правильно написанная
> программа должна собираться от имени пользователя).
> 
> Для дополнительной информации обратитесь к содержимому
> /usr/share/doc/rpm-*/README.ALT .
> 
> Q: у рута сломана локаль!
> 
> A: и не зря.  Системное администрирование -- достаточно
> специфическая задача, требующая повышенного внимания и не
> являющаяся "удобной" по своему определению.
> 
> Крайне не рекомендуется выполнять ежедневную работу от имени root
> -- а для администрирования должно хватить sudo и нормального
> локализованного пользовательского аккаунта.
> 
> Если же вопрос стоит очень остро -- произведите поиск строки LANG
> в файлах в домашнем каталоге администратора.
> 
> Часть II.  notwork troubles
> 
> Q: почему после установки сервера и его активации (в ntsysv,
> DrakConf, /etc/xinetd.d/*) он недоступен из сети?
> 
> A1: по умолчанию в ALT Linux xinetd сконфигурирован с опцией
> only_from = 127.0.0.1, позволяющей доступ к сервисам,
> запускающимся из-под xinetd, только с локальной машины.
> 
> Для обеспечения доступа из сети отредактируйте или
> закомментируйте эту строку в /etc/xinetd.conf; в последнем случае
> настоятельно рекомендуем ввести ограничения по необходимости в
> индивидуальные файлы в каталоге /etc/xinetd.d/ .
> 
> A2: если проблема не в этом -- обратите внимание на настройки
> файрвола (service iptables status или service ipchains status).
> 
> A3: проверьте содержимое файлов /etc/hosts.allow и /etc/hosts.deny
> (XXX есть какой-то TFM на эту тему?)

Q: Почта не ходит!!
По умолчанию, в соответствии с политикой безопасности, postfix
настроен на работу только с локальными почтовыми клиентами, а
так же может отправлять почту на внешние smtp сервера. Если Вам
необходимо получать или пересылать почту через данный сервер с
внешних хостов, отредактируйте файлы конфигурации posfix. Для
нормальной работы postfix необходим доступ к корректно
настроенному серверу DNS.

-- 
Власенко Олег.
Отдел технической поддержки ALT Linux Team.
mailto:cornet@altlinux.ru

[devel] Re: README.ALT wanted (was: I: base utilities for network analisys are now chrooted)

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

Hello cornet,

On Thu, Apr 11, 2002 at 12:45:33PM +0400, cornet wrote:
>
> Q: Почта не ходит!!
> По умолчанию, в соответствии с политикой безопасности, postfix
> настроен на работу только с локальными почтовыми клиентами, а
> так же может отправлять почту на внешние smtp сервера. Если Вам
> необходимо получать или пересылать почту через данный сервер с
> внешних хостов, отредактируйте файлы конфигурации posfix. Для
> нормальной работы postfix необходим доступ к корректно
> настроенному серверу DNS.

Добавить: См. пункт "DNS не работает!!" :)

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] Re: README.ALT wanted (was: I: base utilities for network analisys are now chrooted)

[Igor Homyakov]

Думаю надо еще добавить пару слов про tcb, cо SCO мало кто дело имел
а про OrangeBook еще меньше народу слышало :))

-- 
Igor Homyakov
<homyakov(at)ramax.spb.ru>

[devel] Re: README.ALT wanted

[Michael Shigorin]

[-- Attachment #1.1: Type: text/plain, Size: 1133 bytes --]

On Thu, Apr 11, 2002 at 11:18:28AM +0400, Dmitry V. Levin wrote:
> > И вообще хорошо бы "альтовости" повыносить в отдельный
> > checklist (/README.ALT), дабы людям было легче портироваться.
> > Примерный список Q&A -- думаю, по сервисам и "чего не дают
> > руту".
> Ok, давайте попробуем "вспомнить все", пока еще не поздно.
Последняя версия в аттаче.

Добавлено:
- администрирование CUPS (про admrestart и NoIzvrat)
- ssh root@host
- "почта не ходит" (postfix+dns, <-cornet)
- ls -l /etc/shadow
- PowerChutePlus и пароли

---

m-r & sisyphus readers: устраиваю жуткий спам, считая его в ваших
же интересах.  Если есть дополнения -- срочно шлите!

Кто-то может вспомнить "приколы" с серверами, локалью etc?
Если актуален вопрос вида "Q: как перенести старые пароли из
RH6/*BSD/courier?" -- пишите ответ.

Игрушки (вроде UT) -- наверное, недистроспецифично и скорее
подходит для более отдельного фака?

Имеет ли смысл вписать каким-то боком ссылку на man pam_console?
Это скорее RH[-based] specific, но может быть более чем
неочевидно.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #1.2: README.ALT --]
[-- Type: text/plain, Size: 5402 bytes --]

Часть I.  root squashed

Q: почему руту не ходит почта?

A: в силу того, что читать почту под этим аккаунтом крайне не
рекомендуется (вариант -- запрещено по политике безопасности
дистрибутива), при инсталяции создается почтовый алиас,
переправляющий почту на первого зарегистрированного пользователя
(подразумевается, что это тот же человек, который устанавливал
систему).

Если это не устраивает (нужен другой пользователь), загляните в
/etc/postfix/aliases (после правки необходимо запустить от имени
root команду postalias).


Q: почему руту не дают собирать RPM? Выдается ошибка:
"rpmb: сборка пакетов запрещена для привилегированного пользователя"

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

Для дополнительной информации обратитесь к содержимому
/usr/share/doc/rpm-*/README.ALT .


Q: у рута сломана локаль!

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

Крайне не рекомендуется выполнять ежедневную работу от имени root
-- а для администрирования должно хватить sudo и нормального
локализованного пользовательского аккаунта.

Если же вопрос стоит очень остро -- произведите поиск строки LANG
в файлах в домашнем каталоге администратора.


Q: CUPS не конфигурируется -- выдает ошибки даже после ввода
правильного пароля root!

A: для повышения безопасности CUPS теперь обычно работает от
имени пользователя вместо root, при этом он не может быть
переконфигурирован.  Есть два варианта для выполнения
конфигурирования и других административных задач:

A1: как предлагают разработчики:
service cups admrestart
(делаем административные дела)
service cups restart
(печатаем)

A2: вернуть все к старому варианту: в /etc/cups/cups.conf раскомментарить
runasuser no; 
noizvrat  yes;

Далее
service cups restart
(печатаем и админим в одной обойме)


Q: рута не пускают по ssh, пароль правильный!

A: в приличном обществе принято заходить по ssh пользователем и
лишь тогда делать sudo (или su).  Мотивация -- во-первых, для
административного доступа к системе требуется два пароля;
во-вторых, администрирование в этом случае не анонимно
(идентифицируется по первоначально вошедшему пользователю).

Если в силу каких-либо обстоятельств необходим ssh root login --
скорректируйте параметр PermitRootLogin в файле
/etc/openssh/sshd_config и выполните команду service sshd restart,
но считайте, что вас предупредили.

Если логин осуществляется с сетевой машины -- см. тж. ниже
(насчет hosts.allow).


Часть II.  notwork troubles

Q: почему после установки сервера и его активации (в ntsysv,
DrakConf, /etc/xinetd.d/*) он недоступен из сети?

A1: по умолчанию в ALT Linux xinetd сконфигурирован с опцией
only_from = 127.0.0.1, позволяющей доступ к сервисам,
запускающимся из-под xinetd, только с локальной машины.

Для обеспечения доступа из сети отредактируйте или
закомментируйте эту строку в /etc/xinetd.conf; в последнем случае
настоятельно рекомендуем ввести ограничения по необходимости в
индивидуальные файлы в каталоге /etc/xinetd.d/ .

A2: если проблема не в этом -- обратите внимание на настройки
файрвола (service iptables status или service ipchains status).

A3: проверьте содержимое файлов /etc/hosts.allow и /etc/hosts.deny


Q: Почта не ходит!!

A: по умолчанию в соответствии с политикой безопасности postfix
настроен на работу только с локальными почтовыми клиентами, а
также может отправлять почту на внешние SMTP-сервера. Если вам
необходимо получать или пересылать почту через данный сервер с
внешних хостов, отредактируйте файлы конфигурации posfix.  Для
нормальной работы postfix необходим доступ к корректно
настроенному серверу DNS.


Часть III.  общесистемное администрирование

Q: почему пуст /etc/shadow?  Неужели он не используется?!

A: хуже -- в ALT используется схема TCB, при которой "маленькие
тени" живут в per-user каталогах под /etc/tcb.  Это сперва может
показаться не вполне привычным, но существенно улучшает
безопасность системы и не является катастрофой для администратора
:-)


Q: проблемы с паролями при подключении ИБП APC с "фирменным" ПО
   PowerChutePlus.

A: в старых дистрибутивах пароли шифровались при помощи более
слабых алгоритмов, чем необходимо сейчас -- и, к сожалению, PC+
занимается самодеятельногстью по части обработки паролей, не
используя системные методы аутентификации.

Проблема в том, что он не понимает пароли, закодированные
blowfish.  Если создать пользователя, под которым работает
xpowerschute, и ему назначить пароль, отключив криптование через
blowfish, то все заработает, главное -- ему потом не менять
пароль при включенном blowfish.

Это можно сделать так:

1. Заменить "на секундочку" в файле /etc/pam.d/system-auth строку
password        sufficient      /lib/security/pam_unix.so nullok use_authtok blowfish shadow
на
password        sufficient      /lib/security/pam_unix.so nullok use_authtok md5 shadow

2. Переустановить пароль пользователя, под которым работает
PowerChutePlus, с помощью команды passwd

3. Вернуть файл /etc/pam.d/system-auth в прежнее состояние.



Благодарности
~~~~~~~~~~~~~
Вячеслав Диконов <sdiconov@mail.ru>
Любимов А.В. <avl@l14.ru>
Власенко Олег <cornet@altlinux.ru>
Alexander Bokovoy <a.bokovoy@sam-solutions.net>
Dmitry V. Levin <ldv@alt-linux.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] Re: README.ALT wanted

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

On Sun, Apr 14, 2002 at 10:49:59PM +0300, Michael Shigorin wrote:
> > > И вообще хорошо бы "альтовости" повыносить в отдельный
> > > checklist (/README.ALT), дабы людям было легче портироваться.
> > > Примерный список Q&A -- думаю, по сервисам и "чего не дают
> > > руту".
> > Ok, давайте попробуем "вспомнить все", пока еще не поздно.
> Последняя версия в аттаче.
> 
> Добавлено:
> - администрирование CUPS (про admrestart и NoIzvrat)
> - ssh root@host
> - "почта не ходит" (postfix+dns, <-cornet)
> - ls -l /etc/shadow
> - PowerChutePlus и пароли

Этот пункт (Q: проблемы с паролями при подключении ИБП APC с "фирменным"
ПО) морально устарел; нет, проблемы вряд ли кончились, но предложения по
их устранению надо обновить.

> /etc/openssh/sshd_config и выполните команду service sshd restart,

reload?


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.com/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[devel] Re: README.ALT wanted

[Artem K. Jouravsky]

On Sun, Apr 14, 2002 at 10:49:59PM +0300, Michael Shigorin wrote:
[snip]
> Часть II.  notwork troubles
             ^^^^^^^
[snip]

-- 
Best wishes,
Artem K. Jouravsky,
iFirst Ltd, System Administrator.
-----------------------
Who was that masked man?

Re: [devel] Re: README.ALT wanted

[Michael Shigorin]

[-- Attachment #1.1: Type: text/plain, Size: 1196 bytes --]

On Mon, Apr 15, 2002 at 10:06:42AM +0400, Dmitry V. Levin wrote:
> > - ssh root@host
> > - PowerChutePlus и пароли
> Этот пункт (Q: проблемы с паролями при подключении ИБП APC с
> "фирменным" ПО) морально устарел; нет, проблемы вряд ли
> кончились, но предложения по их устранению надо обновить.
Было:
- password        sufficient      /lib/security/pam_unix.so nullok use_authtok blowfish shadow
+ password        sufficient      /lib/security/pam_unix.so nullok use_authtok md5 shadow

Как это соотносится с текущими возможностями pam_tcb, я не знаю.
В частности, не видно "ручки" для переключения алгоритма
шифрования:

password        required        /lib/security/pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 write_to=tcb

В принципе, про PC+ можно и вынести в более отдельное место (faq
на сайте?) для более спокойного рассмотрения, т.к. проблема, по
большому счету, не ALT-specific, а (non-md5)-specific.

> > /etc/openssh/sshd_config и выполните команду service sshd restart,
> reload?
[fixed] (задумался, но уже боялся заснуть на бэкспейсе :)
Тж. добавил service xinetd sreload.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #1.2: README.ALT --]
[-- Type: text/plain, Size: 5677 bytes --]

Часть I.  root squashed

Q: почему руту не ходит почта?

A: в силу того, что читать почту под этим аккаунтом крайне не
рекомендуется (вариант -- запрещено по политике безопасности
дистрибутива), при инсталяции создается почтовый алиас,
переправляющий почту на первого зарегистрированного пользователя
(подразумевается, что это тот же человек, который устанавливал
систему).

Если это не устраивает (нужен другой пользователь), загляните в
файл /etc/postfix/aliases; после правки необходимо выполнить от
имени root следующую команду:

	postalias


Q: почему руту не дают собирать RPM? Выдается ошибка:
"rpmb: сборка пакетов запрещена для привилегированного пользователя"

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

Для дополнительной информации обратитесь к содержимому
/usr/share/doc/rpm-4.0.4/README.ALT .


Q: у рута сломана локаль!

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

Крайне не рекомендуется выполнять ежедневную работу от имени root
-- а для администрирования должно хватить sudo и нормального
локализованного пользовательского аккаунта.

Если же вопрос стоит очень остро -- произведите поиск строки LANG
в файлах в домашнем каталоге администратора.


Q: CUPS не конфигурируется -- выдает ошибки даже после ввода
правильного пароля root!

A: для повышения безопасности CUPS теперь обычно работает от
имени пользователя вместо root, при этом он не может быть
переконфигурирован.  Есть два варианта для выполнения
конфигурирования и других административных задач:

A1: как предлагают разработчики:

	service cups admrestart

(делаем административные дела)

	service cups restart

(печатаем)

A2: вернуть все к старому варианту: в /etc/cups/cups.conf
раскомментировать

	runasuser no; 
	noizvrat  yes;

Далее

	service cups restart

(печатаем и админим в одной обойме)


Q: рута не пускают по ssh, пароль правильный!

A: в приличном обществе принято заходить по ssh пользователем и
лишь тогда делать sudo (или su).  Мотивация -- во-первых, для
административного доступа к системе требуется два пароля;
во-вторых, администрирование в этом случае не анонимно
(идентифицируется по первоначально вошедшему пользователю).

Если в силу каких-либо обстоятельств необходим ssh root login --
скорректируйте параметр PermitRootLogin в файле
/etc/openssh/sshd_config и выполните команду

	service sshd reload

-- но считайте, что вас предупредили.

Если логин осуществляется с сетевой машины -- см. тж. ниже
(насчет hosts.allow).


Часть II.  notwork troubles

Q: почему после установки сервера и его активации (в ntsysv,
DrakConf, /etc/xinetd.d/*) он недоступен из сети?

A1: по умолчанию в ALT Linux xinetd сконфигурирован с опцией
only_from = 127.0.0.1, позволяющей доступ к сервисам,
запускающимся из-под xinetd, только с локальной машины.

Для обеспечения доступа из сети отредактируйте или
закомментируйте эту строку в /etc/xinetd.conf; в последнем случае
настоятельно рекомендуем ввести ограничения по необходимости в
индивидуальные файлы в каталоге /etc/xinetd.d/ .  После внесения
изменений в конфигурацию xinetd необходимо учесть их командой

	service xinetd sreload

A2: если проблема не в этом -- обратите внимание на настройки
файрвола, которые можно получить при помощи команд

	service iptables status

(для Linux 2.4) или (для Linux 2.2)

	service ipchains status

A3: проверьте содержимое файлов /etc/hosts.allow и /etc/hosts.deny


Q: Почта не ходит!!

A: по умолчанию в соответствии с политикой безопасности postfix
настроен на работу только с локальными почтовыми клиентами, а
также может отправлять почту на внешние SMTP-сервера. Если вам
необходимо получать или пересылать почту через данный сервер с
внешних хостов, отредактируйте файлы конфигурации postfix.  Для
нормальной работы postfix с внешней почтой необходим доступ к
корректно настроенному серверу DNS.


Часть III.  общесистемное администрирование

Q: почему пуст /etc/shadow?  Неужели он не используется?!

A: хуже -- в ALT используется схема TCB, при которой "маленькие
тени" живут в per-user каталогах под /etc/tcb.  Это сперва может
показаться не вполне привычным, но существенно улучшает
безопасность системы и не является катастрофой для администратора
:-)


Q: проблемы с паролями при подключении ИБП APC с "фирменным" ПО
   PowerChutePlus.

A: в старых дистрибутивах пароли шифровались при помощи более
слабых алгоритмов, чем необходимо сейчас -- и, к сожалению, PC+
занимается самодеятельногстью по части обработки паролей, не
используя системные методы аутентификации.

Проблема в том, что он не понимает пароли, закодированные
blowfish.  Если создать пользователя, под которым работает
xpowerschute, и ему назначить пароль, отключив криптование через
blowfish, то все заработает, главное -- ему потом не менять
пароль при включенном blowfish.

Это можно сделать так [ВНИМАНИЕ: устарело с переходом на tcb]:

1. Заменить "на секундочку" в файле /etc/pam.d/system-auth строку
password        sufficient      /lib/security/pam_unix.so nullok use_authtok blowfish shadow
на
password        sufficient      /lib/security/pam_unix.so nullok use_authtok md5 shadow

2. Переустановить пароль пользователя, под которым работает
PowerChutePlus, с помощью команды passwd

3. Вернуть файл /etc/pam.d/system-auth в прежнее состояние.



Благодарности
~~~~~~~~~~~~~
Вячеслав Диконов <sdiconov@mail.ru>
Любимов А.В. <avl@l14.ru>
Власенко Олег <cornet@altlinux.ru>
Alexander Bokovoy <a.bokovoy@sam-solutions.net>
Dmitry V. Levin <ldv@alt-linux.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] Re: README.ALT wanted

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

On Mon, Apr 15, 2002 at 10:59:38AM +0300, Michael Shigorin wrote:
> > > - PowerChutePlus и пароли
> > Этот пункт (Q: проблемы с паролями при подключении ИБП APC с
> > "фирменным" ПО) морально устарел; нет, проблемы вряд ли
> > кончились, но предложения по их устранению надо обновить.
> Было:
> - password        sufficient      /lib/security/pam_unix.so nullok use_authtok blowfish shadow
> + password        sufficient      /lib/security/pam_unix.so nullok use_authtok md5 shadow
> 
> Как это соотносится с текущими возможностями pam_tcb, я не знаю.
> В частности, не видно "ручки" для переключения алгоритма
> шифрования:
> 
> password        required        /lib/security/pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 write_to=tcb

prefix=, см. pam_tcb(5);
для md5: prefix=$1$

> > > /etc/openssh/sshd_config и выполните команду service sshd restart,
> > reload?
> [fixed] (задумался, но уже боялся заснуть на бэкспейсе :)
> Тж. добавил service xinetd sreload.

s/sreload/reload/


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.com/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] Re: README.ALT wanted

[Alexander Bokovoy]

On Mon, Apr 15, 2002 at 10:59:38AM +0300, Michael Shigorin wrote:
> Q: у рута сломана локаль!
> 
> A: и не зря.  Системное администрирование -- достаточно
> специфическая задача, требующая повышенного внимания и не
> являющаяся "удобной" по своему определению.  
Лучше написать:
A: У пользователя root настроена локаль POSIX в целях устранения
возможных проблем с системными сервисами, использующими этот
пользовательский account для своего запуска. В частности, последствия
применения не-POSIX локали для root становятся видны в файлах протоколов
syslog в виде локализованных дат, которые не воспринимаются большинством
анализаторов системных протоколов.

> Крайне не рекомендуется выполнять ежедневную работу от имени root
> -- а для администрирования должно хватить sudo и нормального
> локализованного пользовательского аккаунта.
Так пойдет.

 
> Если же вопрос стоит очень остро -- произведите поиск строки LANG
> в файлах в домашнем каталоге администратора.
Здесь лучше: специфические настройки локали для любого пользователя (в том
числе и root) можно изменить в файле ~/.i18n.

> Q: рута не пускают по ssh, пароль правильный!
> 
> A: в приличном обществе принято заходить по ssh пользователем и
"в приличном обществе" звучит слишком вызывающе, стоит переписать,
используюя более серьезный тон.

> Часть II.  notwork troubles
Network troubles

> Часть III.  общесистемное администрирование
> 
> Q: почему пуст /etc/shadow?  Неужели он не используется?!
> 
> A: хуже -- в ALT используется схема TCB, при которой "маленькие
То же самое -- в описании security features тон должен быть деловым.
Примерный вариант:
"В ALT Linux используется реализация Trusted Computing Base (TCB),
выполненная Rafal Wojtczuk и Solar Designer в рамках проекта Openwall
GNU/*/Linux. В этой модели каждый пользователь имеет собственный
shadow-файл, хранящийся в /etc/tcb/имя_пользователя/shadow, доступ к
которому имеют только сам пользователь (чтение/запись) и программы, 
исполняющиеся с sgid auth. В результате, доступ к паролям конкретного
пользователя не приводит к возможности скомпрометировать всю систему.
О преимуществах и недостатках этой модели подробно описано в tcb(5).
Для всех приложений, работающих в системах с поддержкой NSS (например, ALT
Linux) и использующих только чтение паролей системными средствами, 
схема TCB прозрачна.


-- 
/ Alexander Bokovoy
Software architect and analyst             // SaM-Solutions Ltd.
---
TAPPING?  You POLITICIANS!  Don't you realize that the END of the "Wash
Cycle" is a TREASURED MOMENT for most people?!

[devel] Re: README.ALT wanted

[Michael Shigorin]

[-- Attachment #1.1: Type: text/plain, Size: 1118 bytes --]

On Mon, Apr 15, 2002 at 12:28:02PM +0400, Dmitry V. Levin wrote:
> > password        required        /lib/security/pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 write_to=tcb
> prefix=, см. pam_tcb(5);
> для md5: prefix=$1$
Проверьте -- так?

> > Тж. добавил service xinetd sreload.
> s/sreload/reload/
Вам видней -- [done]


On Mon, Apr 15, 2002 at 11:31:27AM +0300, Alexander Bokovoy wrote:
> > Q: у рута сломана локаль!
> Лучше написать:
[done]

> Здесь лучше: специфические настройки локали для любого пользователя (в том
> числе и root) можно изменить в файле ~/.i18n.
[done]

> > A: в приличном обществе принято заходить по ssh пользователем и
> "в приличном обществе" звучит слишком вызывающе, стоит переписать,
> используюя более серьезный тон.
Проверьте.

> > Часть II.  notwork troubles
> Network troubles
Так было задумано -- или inappropriate?

> > Q: почему пуст /etc/shadow?  Неужели он не используется?!
> То же самое -- в описании security features тон должен быть деловым.
[applied]

---

Итак?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #1.2: README.ALT --]
[-- Type: text/plain, Size: 6364 bytes --]

Часть I.  root squashed

Q: почему руту не ходит почта?

A: в силу того, что читать почту под этим аккаунтом крайне не
рекомендуется (вариант -- запрещено по политике безопасности
дистрибутива), при инсталяции создается почтовый алиас,
переправляющий почту на первого зарегистрированного пользователя
(подразумевается, что это тот же человек, который устанавливал
систему).

Если это не устраивает (нужен другой пользователь), загляните в
файл /etc/postfix/aliases; после правки необходимо выполнить от
имени root следующую команду:

	postalias /etc/postfix/aliases


Q: почему руту не дают собирать RPM? Выдается ошибка:
"rpmb: сборка пакетов запрещена для привилегированного пользователя"

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

Для дополнительной информации обратитесь к содержимому
/usr/share/doc/rpm-4.0.4/README.ALT .


Q: у рута сломана локаль!

A: У пользователя root настроена локаль POSIX в целях устранения
возможных проблем с системными сервисами, использующими этот
пользовательский account для своего запуска. В частности, последствия
применения не-POSIX локали для root становятся видны в файлах протоколов
syslog в виде локализованных дат, которые не воспринимаются большинством
анализаторов системных протоколов.

Крайне не рекомендуется выполнять ежедневную работу от имени root
-- а для администрирования должно хватить sudo и нормального
локализованного пользовательского аккаунта.

Специфические настройки локали для любого пользователя (в том
числе и root) можно изменить в файле ~/.i18n .


Q: CUPS не конфигурируется -- выдает ошибки даже после ввода
правильного пароля root!

A: для повышения безопасности CUPS теперь обычно работает от
имени пользователя вместо root, при этом он не может быть
переконфигурирован.  Есть два варианта для выполнения
конфигурирования и других административных задач:

A1: как предлагают разработчики:

	service cups admrestart

(делаем административные дела)

	service cups restart

(печатаем)

A2: вернуть все к старому варианту: в /etc/cups/cups.conf
раскомментировать

	runasuser no; 
	noizvrat  yes;

Далее

	service cups restart

(печатаем и админим в одной обойме)


Q: рута не пускают по ssh, пароль правильный!

A: обычно принято заходить по ssh пользователем и лишь тогда
делать sudo (или su).  Мотивация -- во-первых, для
административного доступа к системе требуется два пароля;
во-вторых, администрирование в этом случае не анонимно
(идентифицируется по первоначально вошедшему пользователю).

Если в силу каких-либо обстоятельств необходим ssh root login --
скорректируйте параметр PermitRootLogin в файле
/etc/openssh/sshd_config и выполните команду

	service sshd reload

-- но считайте, что вас предупредили.

Если логин осуществляется с сетевой машины -- см. тж. ниже
(насчет hosts.allow).


Часть II.  notwork troubles

Q: почему после установки сервера и его активации (в ntsysv,
DrakConf, /etc/xinetd.d/*) он недоступен из сети?

A1: по умолчанию в ALT Linux xinetd сконфигурирован с опцией
only_from = 127.0.0.1, позволяющей доступ к сервисам,
запускающимся из-под xinetd, только с локальной машины.

Для обеспечения доступа из сети отредактируйте или
закомментируйте эту строку в /etc/xinetd.conf; в последнем случае
настоятельно рекомендуем ввести ограничения по необходимости в
индивидуальные файлы в каталоге /etc/xinetd.d/ .  После внесения
изменений в конфигурацию xinetd необходимо учесть их командой

	service xinetd reload

A2: если проблема не в этом -- обратите внимание на настройки
файрвола, которые можно получить при помощи команд

	service iptables status

(для Linux 2.4) или (для Linux 2.2)

	service ipchains status

A3: проверьте содержимое файлов /etc/hosts.allow и /etc/hosts.deny


Q: Почта не ходит!!

A: по умолчанию в соответствии с политикой безопасности postfix
настроен на работу только с локальными почтовыми клиентами, а
также может отправлять почту на внешние SMTP-сервера. Если вам
необходимо получать или пересылать почту через данный сервер с
внешних хостов, отредактируйте файлы конфигурации postfix.  Для
нормальной работы postfix с внешней почтой необходим доступ к
корректно настроенному серверу DNS.


Часть III.  общесистемное администрирование

Q: почему пуст /etc/shadow?  Неужели он не используется?!

A: в ALT Linux используется реализация Trusted Computing Base
(TCB), выполненная Rafal Wojtczuk и Solar Designer в рамках
проекта Openwall GNU/*/Linux. В этой модели каждый пользователь
имеет собственный shadow-файл, хранящийся в
/etc/tcb/имя_пользователя/shadow, доступ к которому имеют только
сам пользователь (чтение/запись) и программы, исполняющиеся с
sgid auth. В результате, доступ к паролям конкретного
пользователя не приводит к возможности скомпрометировать всю
систему.  О преимуществах и недостатках этой модели подробно
описано в tcb(5).  Для всех приложений, работающих в системах с
поддержкой NSS (например, ALT Linux) и использующих только чтение
паролей системными средствами, схема TCB прозрачна.


Q: проблемы с паролями при подключении ИБП APC с "фирменным" ПО
   PowerChutePlus.

A: в старых дистрибутивах пароли шифровались при помощи более
слабых алгоритмов, чем необходимо сейчас -- и, к сожалению, PC+
занимается самодеятельногстью по части обработки паролей, не
используя системные методы аутентификации.

Проблема в том, что он не понимает пароли, закодированные
blowfish.  Если создать пользователя, под которым работает
xpowerschute, и ему назначить пароль, отключив криптование через
blowfish, то все заработает, главное -- ему потом не менять
пароль при включенном blowfish.

Это можно сделать так:

1. Заменить "на секундочку" в файле /etc/pam.d/system-auth строку
password        required        /lib/security/pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 write_to=tcb
на
password        required        /lib/security/pam_tcb.so use_authtok shadow fork prefix=$1$ count=8 write_to=tcb

2. Переустановить пароль пользователя, под которым работает
PowerChutePlus, с помощью команды passwd

3. Вернуть файл /etc/pam.d/system-auth в прежнее состояние.



Благодарности
~~~~~~~~~~~~~
Вячеслав Диконов <sdiconov@mail.ru>
Любимов А.В. <avl@l14.ru>
Власенко Олег <cornet@altlinux.ru>
Alexander Bokovoy <a.bokovoy@sam-solutions.net>
Dmitry V. Levin <ldv@alt-linux.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[devel] Re: [sisyphus] Re: README.ALT wanted

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

On Mon, Apr 15, 2002 at 01:20:53PM +0300, Michael Shigorin wrote:
> Часть III.  общесистемное администрирование
 
Q: Были внесены изменения в конфигурационные файлы; как синхронизировать
   эти изменения во всех многочисленных chrooted environments,
   используемых в системе?

A: Запустите команду
   /sbin/update_chrooted conf

Q: А если были изменены системные библиотеки?

A: Обычно это происходит в ходе обновления пакетов; в этом случае
   синхронизация библиотек и обновление /etc/ld.so.cache произойдет
   автоматически. В противном случае следует запустить команды
   /sbin/ldconfig
   /sbin/update_chrooted lib

P.S. /sbin/update_chrooted раньше назывался /usr/sbin/update_chrooted.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.com/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[devel] Re: README.ALT wanted

[Michael Shigorin]

[-- Attachment #1.1: Type: text/plain, Size: 365 bytes --]

On Tue, Apr 16, 2002 at 01:52:49PM +0400, Dmitry V. Levin wrote:
> > Часть III.  общесистемное администрирование
> Q: Были внесены изменения в конфигурационные файлы; как синхронизировать
[skip]
[done]

Последняя версия -- в аттаче.  Станислав, заберите, пожалуйста.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #1.2: README.ALT --]
[-- Type: text/plain, Size: 6911 bytes --]

Часть I.  root squashed

Q: почему руту не ходит почта?

A: в силу того, что читать почту под этим аккаунтом крайне не
рекомендуется (вариант -- запрещено по политике безопасности
дистрибутива), при инсталяции создается почтовый алиас,
переправляющий почту на первого зарегистрированного пользователя
(подразумевается, что это тот же человек, который устанавливал
систему).

Если это не устраивает (нужен другой пользователь), загляните в
файл /etc/postfix/aliases; после правки необходимо выполнить от
имени root следующую команду:

	newaliases


Q: почему руту не дают собирать RPM? Выдается ошибка:
"rpmb: сборка пакетов запрещена для привилегированного пользователя"

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

Для дополнительной информации обратитесь к содержимому
/usr/share/doc/rpm-4.0.4/README.ALT .


Q: у рута сломана локаль!

A: У пользователя root настроена локаль POSIX в целях устранения
возможных проблем с системными сервисами, использующими этот
пользовательский account для своего запуска. В частности, последствия
применения не-POSIX локали для root становятся видны в файлах протоколов
syslog в виде локализованных дат, которые не воспринимаются большинством
анализаторов системных протоколов.

Крайне не рекомендуется выполнять ежедневную работу от имени root
-- а для администрирования должно хватить sudo и нормального
локализованного пользовательского аккаунта.

Специфические настройки локали для любого пользователя (в том
числе и root) можно изменить в файле ~/.i18n .


Q: CUPS не конфигурируется -- выдает ошибки даже после ввода
правильного пароля root!

A: для повышения безопасности CUPS теперь обычно работает от
имени пользователя вместо root, при этом он не может быть
переконфигурирован.  Есть два варианта для выполнения
конфигурирования и других административных задач:

A1: как предлагают разработчики:

	service cups admrestart

(делаем административные дела)

	service cups restart

(печатаем)

A2: вернуть все к старому варианту: в /etc/cups/cups.conf
раскомментировать

	runasuser no; 
	noizvrat  yes;

Далее

	service cups restart

(печатаем и админим в одной обойме)


Q: рута не пускают по ssh, пароль правильный!

A: обычно принято заходить по ssh пользователем и лишь тогда
делать sudo (или su).  Мотивация -- во-первых, для
административного доступа к системе требуется два пароля;
во-вторых, администрирование в этом случае не анонимно
(идентифицируется по первоначально вошедшему пользователю).

Если в силу каких-либо обстоятельств необходим ssh root login --
скорректируйте параметр PermitRootLogin в файле
/etc/openssh/sshd_config и выполните команду

	service sshd reload

-- но считайте, что вас предупредили.

Если логин осуществляется с сетевой машины -- см. тж. ниже
(насчет hosts.allow).


Часть II.  notwork troubles

Q: почему после установки сервера и его активации (в ntsysv,
DrakConf, /etc/xinetd.d/*) он недоступен из сети?

A1: по умолчанию в ALT Linux xinetd сконфигурирован с опцией
only_from = 127.0.0.1, позволяющей доступ к сервисам,
запускающимся из-под xinetd, только с локальной машины.

Для обеспечения доступа из сети отредактируйте или
закомментируйте эту строку в /etc/xinetd.conf; в последнем случае
настоятельно рекомендуем ввести ограничения по необходимости в
индивидуальные файлы в каталоге /etc/xinetd.d/ .  После внесения
изменений в конфигурацию xinetd необходимо учесть их командой

	service xinetd reload

A2: если проблема не в этом -- обратите внимание на настройки
файрвола, которые можно получить при помощи команд

	service iptables status

(для Linux 2.4) или (для Linux 2.2)

	service ipchains status

A3: проверьте содержимое файлов /etc/hosts.allow и /etc/hosts.deny


Q: Почта не ходит!!

A: по умолчанию в соответствии с политикой безопасности postfix
настроен на работу только с локальными почтовыми клиентами, а
также может отправлять почту на внешние SMTP-сервера. Если вам
необходимо получать или пересылать почту через данный сервер с
внешних хостов, отредактируйте файлы конфигурации postfix.  Для
нормальной работы postfix с внешней почтой необходим доступ к
корректно настроенному серверу DNS.


Часть III.  общесистемное администрирование

Q: почему пуст /etc/shadow?  Неужели он не используется?!

A: в ALT Linux используется реализация Trusted Computing Base
(TCB), выполненная Rafal Wojtczuk и Solar Designer в рамках
проекта Openwall GNU/*/Linux. В этой модели каждый пользователь
имеет собственный shadow-файл, хранящийся в
/etc/tcb/имя_пользователя/shadow, доступ к которому имеют только
сам пользователь (чтение/запись) и программы, исполняющиеся с
sgid auth. В результате, доступ к паролям конкретного
пользователя не приводит к возможности скомпрометировать всю
систему.  О преимуществах и недостатках этой модели подробно
описано в tcb(5).  Для всех приложений, работающих в системах с
поддержкой NSS (например, ALT Linux) и использующих только чтение
паролей системными средствами, схема TCB прозрачна.


Q: проблемы с паролями при подключении ИБП APC с "фирменным" ПО
   PowerChutePlus.

A: в старых дистрибутивах пароли шифровались при помощи более
слабых алгоритмов, чем необходимо сейчас -- и, к сожалению, PC+
занимается самодеятельногстью по части обработки паролей, не
используя системные методы аутентификации.

Проблема в том, что он не понимает пароли, закодированные
blowfish.  Если создать пользователя, под которым работает
xpowerschute, и ему назначить пароль, отключив криптование через
blowfish, то все заработает, главное -- ему потом не менять
пароль при включенном blowfish.

Это можно сделать так:

1. Заменить "на секундочку" в файле /etc/pam.d/system-auth строку
password        required        /lib/security/pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 write_to=tcb
на
password        required        /lib/security/pam_tcb.so use_authtok shadow fork prefix=$1$ count=8 write_to=tcb

2. Переустановить пароль пользователя, под которым работает
PowerChutePlus, с помощью команды passwd

3. Вернуть файл /etc/pam.d/system-auth в прежнее состояние.


Q: Были внесены изменения в конфигурационные файлы; как
синхронизировать эти изменения во всех многочисленных chrooted
environments, используемых в системе?

A: Запустите команду

	/sbin/update_chrooted conf


Q: А если были изменены системные библиотеки?

A: Обычно это происходит в ходе обновления пакетов; в этом случае
синхронизация библиотек и обновление /etc/ld.so.cache произойдет
автоматически. В противном случае следует запустить команды

	/sbin/ldconfig
	/sbin/update_chrooted lib

P.S. /sbin/update_chrooted раньше назывался
/usr/sbin/update_chrooted .



Благодарности
~~~~~~~~~~~~~
Вячеслав Диконов <sdiconov@mail.ru>
Любимов А.В. <avl@l14.ru>
Власенко Олег <cornet@altlinux.ru>
Alexander Bokovoy <a.bokovoy@sam-solutions.net>
Dmitry V. Levin <ldv@alt-linux.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[devel] Re: README.ALT wanted

[Michael Shigorin]

[-- Attachment #1.1: Type: text/plain, Size: 244 bytes --]

On Mon, Apr 15, 2002 at 12:53:17PM +0300, Michael Shigorin wrote:
> ---
> Итак?

Станислав, я забыл слона -- LPP.  Если еще актуально, см. аттач.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #1.2: README.ALT --]
[-- Type: text/plain, Size: 8194 bytes --]

Вопрос N1: как увидеть текстовый вывод процесса загрузки?

Ответ: в ALT Linux Master используется Linux Progress Patch
(LPP), дающий графическое представление о процессе загрузки при
наличии в системе видеокарты, поддерживающей VESA framebuffer.

При этом сообщения init выдаются на 10-ю консоль (переключение --
Alt-F10), начиная примерно с середины "полоски".

Если вас не устраивает это "нововведение" (желательны текстовые
сообщения или видеокарта не поддерживает vesafb) -- удалите
фрагмент вида "fbprogress=/dev/tty10 vga=NNN" из строки,
передаваемой ядру загрузчиком (см. /etc/lilo.conf или
/boot/grub/menu.lst) и в случае LILO повторно установите
загрузчик выполнением от имени root команды

	lilo

ВНИМАНИЕ: если вы плохо представляете себе процесс загрузки,
перед переконфигурированием GRUB/LILO обратитесь к их
документации и проконсультируйтесь в списках рассылки!



Часть I.  root squashed

Q: почему пользователю root не ходит почта?

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

Если это не устраивает (нужен другой пользователь), загляните в
файл /etc/postfix/aliases; после правки необходимо выполнить от
имени root следующую команду:

	newaliases


Q: почему руту не дают собирать RPM? Выдается ошибка:
"rpmb: сборка пакетов запрещена для привилегированного пользователя"

A: сборка пакетов привилегированным пользователем является
потенциально небезопасной (плюс к тому правильно сделанный пакет
должен собираться от имени пользователя).

Для дополнительной информации обратитесь к содержимому
/usr/share/doc/rpm-4.0.4/README.ALT .


Q: у рута сломана локаль!

A: У пользователя root настроена локаль POSIX в целях устранения
возможных проблем с системными сервисами, использующими этот
пользовательский аккаунт для своего запуска. В частности, последствия
применения не-POSIX локали для root становятся видны в файлах протоколов
syslog в виде локализованных дат, которые не воспринимаются большинством
анализаторов системных протоколов.

Крайне не рекомендуется выполнять ежедневную работу от имени root
-- а для администрирования должно хватить sudo и нормального
локализованного пользовательского аккаунта.

Специфические настройки локали для любого пользователя (в том
числе и root) можно изменить в файле ~/.i18n .


Q: CUPS не конфигурируется -- выдает ошибки даже после ввода
правильного пароля root!

A: для повышения безопасности CUPS теперь обычно работает от
имени пользователя вместо root, при этом он не может быть
переконфигурирован.  Есть два варианта для выполнения
конфигурирования и других административных задач:

A1: как предлагают разработчики:

	service cups admrestart

(делаем административные дела)

	service cups restart

(печатаем)

A2: вернуть все к старому варианту: в /etc/cups/cups.conf
раскомментировать

	runasuser no; 
	noizvrat  yes;

Далее

	service cups restart

(печатаем и админим в одной обойме)


Q: рута не пускают по ssh, пароль правильный!

A: обычно принято заходить по ssh пользователем и лишь тогда
делать sudo (или su).  Мотивация -- во-первых, для
административного доступа к системе требуется два пароля;
во-вторых, администрирование в этом случае не анонимно
(идентифицируется по первоначально вошедшему пользователю).

Если в силу каких-либо обстоятельств необходим ssh root login --
скорректируйте параметр PermitRootLogin в файле
/etc/openssh/sshd_config и выполните команду

	service sshd reload

-- но считайте, что вас предупредили.

Если логин осуществляется с сетевой машины -- см. тж. ниже
(насчет hosts.allow).

Комментарий специалиста: 
> Мне не нравится это объяснение, ибо оно склоняет пользователя к
> замене "ssh root@remotehost" на "ssh remotehost" c последующим
> "su -"; это очевидным образом может значительно ослабить
> безопасность root@remotehost, если пользователь делает там,
> помимо "su -", что-то еще. Я в таких случаях создаю специальный
> (только для "su -") su-user@remotehost и помещаю его в группу
> wheel, исключая тем самым user->root compromise через su.



Часть II.  notwork troubles

Q: почему после установки сервера и его активации (в ntsysv,
DrakConf, /etc/xinetd.d/*) он недоступен из сети?

A1: по умолчанию в ALT Linux xinetd сконфигурирован с опцией
only_from = 127.0.0.1, разрешающей доступ к сервисам,
запускающимся из-под xinetd, только с локальной машины.

Для обеспечения доступа из сети отредактируйте или
закомментируйте эту строку в /etc/xinetd.conf; в последнем случае
настоятельно рекомендуем ввести ограничения по необходимости в
индивидуальные файлы в каталоге /etc/xinetd.d/ .  После внесения
изменений в конфигурацию xinetd необходимо учесть их командой

	service xinetd reload

A2: если проблема не в этом -- обратите внимание на настройки
файрвола, которые можно получить при помощи команд

	service iptables status

(для Linux 2.4) или (для Linux 2.2)

	service ipchains status

A3: проверьте содержимое файлов /etc/hosts.allow и /etc/hosts.deny


Q: Почта не ходит!!

A: по умолчанию в соответствии с политикой безопасности postfix
настроен на работу только с локальными почтовыми клиентами, а
также может отправлять почту на внешние SMTP-сервера. Если вам
необходимо получать или пересылать почту через данный сервер с
внешних хостов, отредактируйте файлы конфигурации postfix.  Для
нормальной работы postfix с внешней почтой необходим доступ к
корректно настроенному серверу DNS.


Часть III.  общесистемное администрирование

Q: почему пуст /etc/shadow?  Неужели он не используется?!

A: в ALT Linux используется реализация Trusted Computing Base
(TCB), выполненная Rafal Wojtczuk и Solar Designer в рамках
проекта Openwall GNU/*/Linux. В этой модели каждый пользователь
имеет собственный shadow-файл, хранящийся в
/etc/tcb/имя_пользователя/shadow, доступ к которому имеют только
сам пользователь (чтение/запись) и программы, исполняющиеся с
sgid auth. В результате, доступ к паролям конкретного
пользователя не приводит к возможности скомпрометировать всю
систему.  О преимуществах и недостатках этой модели подробно
описано в tcb(5).  Для всех приложений, работающих в системах с
поддержкой NSS (таких как ALT Linux) и использующих только чтение
паролей системными средствами, схема TCB прозрачна.


Q: проблемы с паролями при подключении ИБП APC с "фирменным" ПО
   PowerChutePlus.

A: в старых дистрибутивах пароли шифровались при помощи более
слабых алгоритмов, чем необходимо сейчас -- и, к сожалению, PC+
занимается самодеятельногстью по части обработки паролей, не
используя системные методы аутентификации.

Проблема в том, что он не понимает пароли, закодированные
blowfish.  Если создать пользователя, под которым работает
xpowerschute, и ему назначить пароль, отключив криптование через
blowfish, то все заработает, главное -- ему потом не менять
пароль при включенном blowfish.

Это можно сделать так:

1. Заменить "на секундочку" в файле /etc/pam.d/system-auth строку
password        required        /lib/security/pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 write_to=tcb
на
password        required        /lib/security/pam_tcb.so use_authtok shadow fork prefix=$1$ count=8 write_to=tcb

2. Переустановить пароль пользователя, под которым работает
PowerChutePlus, с помощью команды passwd

3. Вернуть файл /etc/pam.d/system-auth в прежнее состояние.


Q: Были внесены изменения в конфигурационные файлы; как
синхронизировать эти изменения во всех многочисленных chrooted
environments, используемых в системе?

A: Запустите команду

	/sbin/update_chrooted conf


Q: А если были изменены системные библиотеки?

A: Обычно это происходит в ходе обновления пакетов; в этом случае
синхронизация библиотек и обновление /etc/ld.so.cache произойдет
автоматически. В противном случае следует запустить команды

	/sbin/ldconfig
	/sbin/update_chrooted lib



Благодарности
~~~~~~~~~~~~~
Вячеслав Диконов <sdiconov@mail.ru>
Любимов А.В. <avl@l14.ru>
Власенко Олег <cornet@altlinux.ru>
Alexander Bokovoy <a.bokovoy@sam-solutions.net>
Dmitry V. Levin <ldv@alt-linux.org>
Victor Forsyuk <victor@ksi-linux.com>

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

[devel] Re: [sisyphus] I: base utilities for network analisys are now chrooted

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

On Tue, Apr 09, 2002 at 11:04:09PM +0400, Dmitry V. Levin wrote:
> По окончании сегодняшней синхронизации в Сизифе основные средства
> анализа сети chroot'изированы.

Теперь к ним добавился nmap (2.54BETA32-alt2), можно тестировать.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.com/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] I: base utilities for network analisys are now chrooted

[Volkov Serge]

On Tue, 9 Apr 2002 23:04:09 +0400
"Dmitry V. Levin" <ldv@alt-linux.org> wrote:

> Greetings!
> 
> По окончании сегодняшней синхронизации в Сизифе основные средства
> анализа сети chroot'изированы.
> 
> Это значит, что еще до начала работы с пакетами из сети процесс будет
> находится в chroot'е (/var/resolv) с правами пользователя (даже если был
> запущен root'ом).
> 
> Изменениям подверглись следующие пакеты:
> chrooted-resolv
> iputils
> ngrep
> tcpdump
> traceroute
> 
> Новую технологию защиты поддерживают следующие программы:
> /bin/ping
> /usr/sbin/arping
> /usr/sbin/clockdiff
> /usr/sbin/ping6
> /usr/sbin/tracepath
> /usr/sbin/tracepath6
> /usr/sbin/traceroute6
> /usr/sbin/traceroute
> /usr/sbin/tcpdump
> /usr/bin/ngrep
> 
> Насколько мне известно, ущерба функциональности ни одной из этих программ
> не нанесено.
> 
> P.S. Господа администраторы, по окончании внесения изменения в любой из
>      нижеперечисленных файлов, не забудьте запустить команду
>      "/usr/sbin/update_chrooted conf"
>      Список файлов:
>      /etc/{localtime,hosts,services,{host,nsswitch,resolv}.conf}
> 
> 
> Regards,
> 	Dmitry
> 
Насколько я понимаю это все попадет в Мастер, тогда надо добавить эту информацию как README.FIRST иначе могут возникнуть лишние вопросы.


-- 
With best wishes, Volkov Serge		
Network Administrator/Security Administrator