Re: [sisyphus] По поводу /usr/sbin/control и su

Re: [sisyphus] По поводу /usr/sbin/control и su

[Dmitry V. Levin]

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

On Tue, Apr 01, 2003 at 04:14:52AM +0700, Alexey Morozov wrote:
> "Возвращаясь к напечатанному" (http://www.altlinux.ru/pipermail/sisyphus/2003-January/037979.html)
> 
> Права /bin/su после массового апгрейда стали 0755 root root.
> Смутно припоминаю, что в процессе апгрейда несколько раз говорилось что-то
> типа "no such facility <имярек>", в числе которых был su. По счастью,
> обнаружилась рутовая консолька, поэтому удалось сказать
> 
> /usr/sbin/control su wheelonly
> 
> после чего все стало приемлемо. Обновлялся до su-0.60-alt15,
> control-0.5.1-alt1. Возникает вопрос: кто виноват и что делать?

1. Имело место обновление со старого непод'control'ного su до нового
под'control'ного. На момент обновления ещё не было установлено правила
сохранения текущего состояния su, ввиду чего по окончании обновления
состояния su было выставлено в "restricted".

2. Поскольку обновление завершено, осталось запустить control и проверить,
все ли значения соответствуют ожидаемым. При дальнейших обновлениях su (и
др.) их нынешние состояния будут сохранены.

3. Если кто-нибудь придумает способ решения проблемы обновления в п.1,
который бы не жертвовал безопасностью системы на момент обновления или по
окончании обновления, то это стоит обсудить.


--
ldv

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

[sisyphus] По поводу /usr/sbin/control и su

[Alexey Morozov]

"Возвращаясь к напечатанному" (http://www.altlinux.ru/pipermail/sisyphus/2003-January/037979.html)

Права /bin/su после массового апгрейда стали 0755 root root.
Смутно припоминаю, что в процессе апгрейда несколько раз говорилось что-то
типа "no such facility <имярек>", в числе которых был su. По счастью,
обнаружилась рутовая консолька, поэтому удалось сказать

/usr/sbin/control su wheelonly

после чего все стало приемлемо. Обновлялся до su-0.60-alt15,
control-0.5.1-alt1. Возникает вопрос: кто виноват и что делать?

Re: [sisyphus] По поводу /usr/sbin/control и su

[Alexey Morozov]

On Tue, Apr 01, 2003 at 01:02:06AM +0400, Dmitry V. Levin wrote:
> 1. Имело место обновление со старого непод'control'ного su до нового
> под'control'ного. На момент обновления ещё не было установлено правила
> сохранения текущего состояния su, ввиду чего по окончании обновления
> состояния su было выставлено в "restricted".
> 
> 2. Поскольку обновление завершено, осталось запустить control и проверить,
> все ли значения соответствуют ожидаемым. При дальнейших обновлениях su (и
> др.) их нынешние состояния будут сохранены.
Ну, это, в общем, уже более-менее понятно.

> 3. Если кто-нибудь придумает способ решения проблемы обновления в п.1,
> который бы не жертвовал безопасностью системы на момент обновления или по
> окончании обновления, то это стоит обсудить.
Гхм... (Шёпотом, чтоб не убили сразу): добавлять фазу интерактивной
конфигурации в пэкедж-мэнеджер, как в... ой!.. молчу!..

Впрочем, если серьезно, то нынешняя ситуация чревата капитальным DoS'ом,
особенно в условиях удаленного или автоматического пакетного обновления.
Как ее решать? А точно не удастся подобрать каким-либо "автоматическим
способом" конфигурацию control'а, которая бы более-менее соответствовала
настройкам по состоянию до начала обновления? Ведь не секрет, что количество
людей, правящих ПАМовские настройки сравнительно невелико, а людей,
_серьезно_ правящих /etc/pam.d/* - и того меньше. То есть, довольно велики
шансы попасть на дистрибутивную или около того конфигурацию некоторой
службы. Ну, то есть, например, в случае su, я думаю, подавляющее большинство
устроил бы public или wheel, в зависимости от того, была ли включена у них
pam_wheel.so в /etc/pam.d/su до обновления или нет. То есть, понятно, что
не серебряная пуля, но и не то <beep> с машиной, затерянной в какой-нибудь
давно не открывавшейся серверной посреди глухой сибирской тайги (вариант:
аризонской пустыни, южноафриканской саванны).

Re: [sisyphus] По поводу /usr/sbin/control и su

[Vitaly Ostanin]

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

On Tue, 1 Apr 2003 01:02:06 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

<skipped/>

> 3. Если кто-нибудь придумает способ решения проблемы обновления
> в п.1, который бы не жертвовал безопасностью системы на момент
> обновления или по окончании обновления, то это стоит обсудить.

Уже предлагалось - выводить осмысленное предупреждение вместо
"no such facility".

Текущий вариант не то, чтобы жертвует безопасностью системы - он
жертвует доступом к администрированию системы.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

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

Re: [sisyphus] По поводу /usr/sbin/control и su

[Dmitry V. Levin]

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

On Tue, Apr 01, 2003 at 08:35:24AM +0700, Alexey Morozov wrote:
> On Tue, Apr 01, 2003 at 01:02:06AM +0400, Dmitry V. Levin wrote:
> > 2. Поскольку обновление завершено, осталось запустить control и проверить,
> > все ли значения соответствуют ожидаемым. При дальнейших обновлениях su (и
> > др.) их нынешние состояния будут сохранены.
> Ну, это, в общем, уже более-менее понятно.
> 
> > 3. Если кто-нибудь придумает способ решения проблемы обновления в п.1,
> > который бы не жертвовал безопасностью системы на момент обновления или по
> > окончании обновления, то это стоит обсудить.
> Гхм... (Шёпотом, чтоб не убили сразу): добавлять фазу интерактивной
> конфигурации в пэкедж-мэнеджер, как в... ой!.. молчу!..
> 
> Впрочем, если серьезно, то нынешняя ситуация чревата капитальным DoS'ом,
> особенно в условиях удаленного или автоматического пакетного обновления.
> Как ее решать? А точно не удастся подобрать каким-либо "автоматическим
> способом" конфигурацию control'а, которая бы более-менее соответствовала
> настройкам по состоянию до начала обновления? Ведь не секрет, что количество
> людей, правящих ПАМовские настройки сравнительно невелико, а людей,
> _серьезно_ правящих /etc/pam.d/* - и того меньше. То есть, довольно велики
> шансы попасть на дистрибутивную или около того конфигурацию некоторой
> службы. Ну, то есть, например, в случае su, я думаю, подавляющее большинство
> устроил бы public или wheel, в зависимости от того, была ли включена у них
> pam_wheel.so в /etc/pam.d/su до обновления или нет. То есть, понятно, что
> не серебряная пуля, но и не то <beep> с машиной, затерянной в какой-нибудь
> давно не открывавшейся серверной посреди глухой сибирской тайги (вариант:
> аризонской пустыни, южноафриканской саванны).

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


--
ldv

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

[sisyphus] Re: По поводу /usr/sbin/control и su

[Michael Shigorin]

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

On Tue, Apr 01, 2003 at 08:35:24AM +0700, Alexey Morozov wrote:
> > 3. Если кто-нибудь придумает способ решения проблемы обновления в п.1,
> Впрочем, если серьезно, то нынешняя ситуация чревата капитальным DoS'ом,

(шепотом, чтоб не убили) зато безопасно =]

> Ну, то есть, например, в случае su, я думаю, подавляющее
> большинство устроил бы public или wheel, в зависимости от того,

...есть ли у нас кто-то в группе wheel на момент обновления
пакета, в конце концов.

** все мы задним умом крепки :(

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

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

[sisyphus] Re: По поводу /usr/sbin/control и su

[Artem K. Jouravsky]

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

On Tue, Apr 01, 2003 at 07:52:48PM +0300, Michael Shigorin wrote:
> On Tue, Apr 01, 2003 at 08:35:24AM +0700, Alexey Morozov wrote:
> > > 3. Если кто-нибудь придумает способ решения проблемы обновления в п.1,
> > Впрочем, если серьезно, то нынешняя ситуация чревата капитальным DoS'ом,
> 
> (шепотом, чтоб не убили) зато безопасно =]
> 
> > Ну, то есть, например, в случае su, я думаю, подавляющее
> > большинство устроил бы public или wheel, в зависимости от того,
> 
> ...есть ли у нас кто-то в группе wheel на момент обновления
> пакета, в конце концов.
Кстати, нельзя ли это проверять? И выводить предупреждение, если нету?
Чтобы человек не покидал рутовую консоль.


-- 
Best wishes,
	Artem K. Jouravsky.  
  JabberID: ujo@jabber.ru
iFirst Ltd, System Administrator.
-----------------------
We are a 100% Microsoft Shop.

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

Re: [sisyphus] По поводу /usr/sbin/control и su

[Dmitry V. Levin]

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

On Wed, Apr 02, 2003 at 04:41:44PM +0700, Alexey Morozov wrote:
> > > устроил бы public или wheel, в зависимости от того, была ли включена у них
> > > pam_wheel.so в /etc/pam.d/su до обновления или нет. То есть, понятно, что
> > > не серебряная пуля, но и не то <beep> с машиной, затерянной в какой-нибудь
> > > давно не открывавшейся серверной посреди глухой сибирской тайги (вариант:
> > > аризонской пустыни, южноафриканской саванны).
> > Проблема как раз в том, что эвристические соображения, позволяющие
> > установить режим, на момент установки нового пакета ещё не установлены.
> PreReq: su >= XX.YY-altZZ для control?

Имеет место обратная зависимость.

> Или оно в принудительном порядке захочет su? :-( Хех... Впору вводить
> CondPreReq... Ну, или создавать отдельно пакет со _всей_ конвертационной
> логикой (ну, по крайней мере, логикой, необходимой для конвертации настроек
> дистрибутивных сервисов) и PreReq'uire'ить (эко, сказанул) его в control.
> И эта логика уже самостоятельно определяла бы, что установлены, н-р,
> su, ssh и их неплохо б ковертнуть, а вот sudo не установлен, и поэтому можно
> не напрягаться.
> 
> Ну, то есть, для данного конкретного случая, уже, пожалуй, "поздняк метацца,
> прокомпостированно", но в будущем, видимо, в подобных случаях имеет смысл
> подстраховываться...

И все-таки предупреждение в control-restore я добавлю.


--
ldv

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

Re: [sisyphus] По поводу /usr/sbin/control и su

[Alexey Morozov]

On Tue, Apr 01, 2003 at 07:02:07PM +0400, Dmitry V. Levin wrote:
> > устроил бы public или wheel, в зависимости от того, была ли включена у них
> > pam_wheel.so в /etc/pam.d/su до обновления или нет. То есть, понятно, что
> > не серебряная пуля, но и не то <beep> с машиной, затерянной в какой-нибудь
> > давно не открывавшейся серверной посреди глухой сибирской тайги (вариант:
> > аризонской пустыни, южноафриканской саванны).
> Проблема как раз в том, что эвристические соображения, позволяющие
> установить режим, на момент установки нового пакета ещё не установлены.
PreReq: su >= XX.YY-altZZ для control?
Или оно в принудительном порядке захочет su? :-( Хех... Впору вводить
CondPreReq... Ну, или создавать отдельно пакет со _всей_ конвертационной
логикой (ну, по крайней мере, логикой, необходимой для конвертации настроек
дистрибутивных сервисов) и PreReq'uire'ить (эко, сказанул) его в control.
И эта логика уже самостоятельно определяла бы, что установлены, н-р,
su, ssh и их неплохо б ковертнуть, а вот sudo не установлен, и поэтому можно
не напрягаться.

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

Re: [sisyphus] По поводу /usr/sbin/control и su

[Alexey Morozov]

On Wed, Apr 02, 2003 at 01:24:04PM +0400, Dmitry V. Levin wrote:
> > > Проблема как раз в том, что эвристические соображения, позволяющие
> > > установить режим, на момент установки нового пакета ещё не установлены.
> > PreReq: su >= XX.YY-altZZ для control?
> Имеет место обратная зависимость.
Э-э-э, не...
В том-то весь и прикол, что control должен требовать версий пакетов,
которые знают про этот самый контрол. Но при этом если некоторая служба,
подпадающая под обслуживание контролом, отсутствует в момент установки
контрола, то она не должна автоматически дотягиваться. Ну, типа, как
condrestart в скриптах. Именно поэтому я придумал CondPreReq. Кстати, а 
Conflicts: su < XX.YY-altZZ в _control.spec_ не поможет? 

> > Ну, то есть, для данного конкретного случая, уже, пожалуй, "поздняк метацца,
> > прокомпостированно", но в будущем, видимо, в подобных случаях имеет смысл
> > подстраховываться...
> И все-таки предупреждение в control-restore я добавлю.
Да, видимо, но это не спасет, если апдейтится сто тыщ мильонов пакетов,
разом, cкажем, при дист-апгрейде. Вряд ли кто-то внимательно глядит глазами,
что там rpm пишет, проще в логи потом глядеть. Но для данного конкретного
случая нужно именно "отслеживание процесса", а не результата.