[sisyphus] chroot

[sisyphus] chroot

[Dmitry E. Oboukhov]

Объясните плз смысл запихивания сервисов под сабж.
На ядре 2.4 вроде без проблемм из под сабжа можно
выбраться, зачем тогда дополнительный гимор с
update chroot итд ?

Re: [sisyphus] chroot

[Dmitry V. Levin]

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

On Mon, Sep 23, 2002 at 12:08:43PM +0400, Dmitry E. Oboukhov wrote:
> Объясните плз смысл запихивания сервисов под сабж.
> На ядре 2.4 вроде без проблемм из под сабжа можно

Что значит "вроде без проблем"?


--
ldv

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

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

Dmitry V. Levin wrote:

>On Mon, Sep 23, 2002 at 12:08:43PM +0400, Dmitry E. Oboukhov wrote:
>  
>
>>Объясните плз смысл запихивания сервисов под сабж.
>>На ядре 2.4 вроде без проблемм из под сабжа можно
>>    
>>
>
>Что значит "вроде без проблем"?
>
>  
>
пролетала тут недавно ссылка алгоритма выхода из под сабжа,
я ее проглядывал, достаточно подробный алгоритм...

Re: [sisyphus] chroot

[Dmitry V. Levin]

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

On Mon, Sep 23, 2002 at 12:29:38PM +0400, Dmitry E. Oboukhov wrote:
> >>Объясните плз смысл запихивания сервисов под сабж.
> >>На ядре 2.4 вроде без проблемм из под сабжа можно
> >
> >Что значит "вроде без проблем"?
> >
> пролетала тут недавно ссылка алгоритма выхода из под сабжа,
> я ее проглядывал, достаточно подробный алгоритм...

Пожалуйста, будьте последовательны, и публикуйте информацию в полном виде,
иначе люди подумают, будто Вы занимаетесь распространением слухов.


--
ldv

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

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

Dmitry V. Levin wrote:

>On Mon, Sep 23, 2002 at 12:29:38PM +0400, Dmitry E. Oboukhov wrote:
>  
>
>>>>Объясните плз смысл запихивания сервисов под сабж.
>>>>На ядре 2.4 вроде без проблемм из под сабжа можно
>>>>        
>>>>
>>>Что значит "вроде без проблем"?
>>>
>>>      
>>>
>>пролетала тут недавно ссылка алгоритма выхода из под сабжа,
>>я ее проглядывал, достаточно подробный алгоритм...
>>    
>>
>
>Пожалуйста, будьте последовательны, и публикуйте информацию в полном виде,
>иначе люди подумают, будто Вы занимаетесь распространением слухов.
>
ок, признаю свою ошибку,
ссылку сейчас найду, а пока гляньте в архив Community
там тред с темами
"Что такое chroot environments"
тоже довольно подробно алгоритм написан. (автор ASA)

Смысл в том, что если сервис работает не от рута, зачем его пихать в чрут?
а если от рута, то из под чрута - легко можно выбраться...

смысл сабжа тогда ?

Re: [sisyphus] chroot

[Dmitry V. Levin]

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

On Mon, Sep 23, 2002 at 12:54:02PM +0400, Dmitry E. Oboukhov wrote:
> >>>>Объясните плз смысл запихивания сервисов под сабж.
> >>>>На ядре 2.4 вроде без проблемм из под сабжа можно
> >>>>
> >>>Что значит "вроде без проблем"?
> >>>
> >>пролетала тут недавно ссылка алгоритма выхода из под сабжа,
> >>я ее проглядывал, достаточно подробный алгоритм...
> 
> [...]
> 
> ссылку сейчас найду, а пока гляньте в архив Community
> там тред с темами
> "Что такое chroot environments"
> тоже довольно подробно алгоритм написан. (автор ASA)
> 
> Смысл в том, что если сервис работает не от рута, зачем его пихать в чрут?
> а если от рута, то из под чрута - легко можно выбраться...

Правильно.
Под чрутизацией понимают помещение в специально сконструированный chroot jail
непривилегированных (или слабопривилегированных процессов).

Я об этом немного рассказывал на семинаре "Свободные программы:
философия, технология, бизнес" более года назад
(http://www.altlinux.ru/index.php?module=articles&action=show&artid=5)

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

Когда про какой-то сервис я говорю, что он чрутизирован, то подразумеваю,
что его процессы выполняются в специально сконструированном chroot jail в
непривилегированном виде, достаточном для того, чтобы не иметь теоретической
возможности оттуда выбраться.


--
ldv

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

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

>
>
>Правильно.
>Под чрутизацией понимают помещение в специально сконструированный chroot jail
>непривилегированных (или слабопривилегированных процессов).
>
>Я об этом немного рассказывал на семинаре "Свободные программы:
>философия, технология, бизнес" более года назад
>(http://www.altlinux.ru/index.php?module=articles&action=show&artid=5)
>
>Если чрутизация выполнена некорректно (процесс слишком привилегированный
>или имеет недопустимые формы доступа к чувствительным ресурсам), то от нее
>не будет никакой пользы.
>
>Когда про какой-то сервис я говорю, что он чрутизирован, то подразумеваю,
>что его процессы выполняются в специально сконструированном chroot jail в
>непривилегированном виде, достаточном для того, чтобы не иметь теоретической
>возможности оттуда выбраться.
>

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

При чрутизации конечно можно поменьше думать о правах,
тк файловое пространство все отдано программе.

делать и то и другое - смысл? для самоуспокоения ?
или здесь ситуация такая же как с фаерволом: в принципе
фаерволы нафиг не нужны - если _все_ сервера правильно
настроены, то надобности в нем нет, но наличие фаервола
дает админу уверенность, что если он где-то что-то
проглядел, то вот тут тоже закрыто...
хотя такая уверенность может и ослабить бдительность ;)

Re: [sisyphus] chroot

[Dmitry V. Levin]

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

On Mon, Sep 23, 2002 at 01:39:44PM +0400, Dmitry E. Oboukhov wrote:
> почитал, достаточно интересно, однако вопрос остается:
> разве разграничение прав не достаточно надежно ?
> я так понимаю, что если для каждого приложения завести
> пользователя и группу и расставить права доступа
> на каталоги и файлы, то можно получить ситуацию ровно
> ту же самую: приложение сможет максимум - убить себя,
> и то, если оно будет являться владельцем своих файлов.
> 
> При чрутизации конечно можно поменьше думать о правах,
> тк файловое пространство все отдано программе.

Помещение в chroot позволяет реализовать разграничение доступа более
эффективно.


--
ldv

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

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

Dmitry V. Levin wrote:

>On Mon, Sep 23, 2002 at 01:39:44PM +0400, Dmitry E. Oboukhov wrote:
>  
>
>>почитал, достаточно интересно, однако вопрос остается:
>>разве разграничение прав не достаточно надежно ?
>>я так понимаю, что если для каждого приложения завести
>>пользователя и группу и расставить права доступа
>>на каталоги и файлы, то можно получить ситуацию ровно
>>ту же самую: приложение сможет максимум - убить себя,
>>и то, если оно будет являться владельцем своих файлов.
>>
>>При чрутизации конечно можно поменьше думать о правах,
>>тк файловое пространство все отдано программе.
>>    
>>
>
>Помещение в chroot позволяет реализовать разграничение доступа более
>эффективно.
>
>  
>
"чем армяне лучше чем грузины ? - чем грузины..."

в чем эта большая эффективность ?

может наоборот меньшая? так как чрут действует расслабляюще (пример с 
фаерволом
я выше привел ;)

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

>
>
>тем что приложение проламывается, получает права рута и поехали
>веселится в системе. а когда оно в окружении оно тока в окружении и
>навеселится..
>  
>

Если приложение получает права рута в чруте,
то спокойно может из под него вылезти... (почитай тред выше)

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

я предложил обоснование: закрытие _возможно уязвимых мест_, которые
имеют уязвимости по причине того, что где-то что-то недосмотренно
(аналог - фаерволы), однако тут есть и недостаток - расслабляющее
действие на людей: "У нас это работает под чрутом, значит тут все ок" -
а на самом деле мб не ок ?

Re: [sisyphus] chroot

[Anton V. Boyarshinov]

Добрый день

On Mon, 23 Sep 2002 13:39:44 +0400
"Dmitry E. Oboukhov" <node@avanto.mpei.ac.ru> wrote:

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

А также может использовать локальную уязвимость для эскалации
своих прав. Что под chroot как правило невозможно.

Антон
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
  3:00pm  up 31 days,  7:15,  6 users,  load average: 0.22, 0.05,
0.01

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

Anton V. Boyarshinov wrote:

>Добрый день
>
>On Mon, 23 Sep 2002 13:39:44 +0400
>"Dmitry E. Oboukhov" <node@avanto.mpei.ac.ru> wrote:
>
>  
>
>>я так понимаю, что если для каждого приложения завести
>>пользователя и группу и расставить права доступа
>>на каталоги и файлы, то можно получить ситуацию ровно
>>ту же самую: приложение сможет максимум - убить себя,
>>и то, если оно будет являться владельцем своих файлов.
>>    
>>
>
>А также может использовать локальную уязвимость для эскалации
>своих прав. Что под chroot как правило невозможно.
>
>  
>
почему ?

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

>
>
>DEO> я предложил обоснование: закрытие _возможно уязвимых мест_, которые
>DEO> имеют уязвимости по причине того, что где-то что-то недосмотренно
>DEO> (аналог - фаерволы), однако тут есть и недостаток - расслабляющее
>DEO> действие на людей: "У нас это работает под чрутом, значит тут все ок" -
>DEO> а на самом деле мб не ок ?
>
>Какой вы Дмитрий, однако, скептический.. :-)..  Хуже не будет.. :-)..
>
>  
>

я как раз и привел чем хуже будет ... ;)
а скептически надо относиться к каждой защите, иначе она не будет защитой

Re: [sisyphus] chroot

[Alexey V. Lubimov]

> я предложил обоснование: закрытие _возможно уязвимых мест_, которые
> имеют уязвимости по причине того, что где-то что-то недосмотренно
> (аналог - фаерволы), однако тут есть и недостаток - расслабляющее
> действие на людей: "У нас это работает под чрутом, значит тут все ок" -
> а на самом деле мб не ок ?

Область рассмотрения (доказательства безопасности) для нечрут сервиса - вся система.
Область рассмотрения для правильно чрутизированного сервиса - область чрута.

Попробуйте написать доказательство для того и  другого случая и вставить проверки в инитскрипты для сервиса и все вопросы у вас сразу закончатся.

-- 
С уважением, Алексей Любимов avl@cad.ru

Re: [sisyphus] chroot

[Dmitry V. Levin]

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

On Mon, Sep 23, 2002 at 02:56:48PM +0400, Dmitry E. Oboukhov wrote:
> >тем что приложение проламывается, получает права рута и поехали
> >веселится в системе. а когда оно в окружении оно тока в окружении и
> >навеселится..
> 
> Если приложение получает права рута в чруте,
> то спокойно может из под него вылезти... (почитай тред выше)
> 
> а если оно в чруте не работает от рута, то имхо достаточно юниксовой
> системы разграничения прав - тоже не понятно зачем чрут ?
> 
> я предложил обоснование: закрытие _возможно уязвимых мест_, которые
> имеют уязвимости по причине того, что где-то что-то недосмотренно
> (аналог - фаерволы), однако тут есть и недостаток - расслабляющее
> действие на людей: "У нас это работает под чрутом, значит тут все ок" -
> а на самом деле мб не ок ?

Это не что иное, как воплощение "the least privilege principle" -
помещая процесс в chroot jail, мы можем минимизировать доступ к файлам в
гораздо большей степени, чем без использования этой технологии.
В частности, помимо обычных файлов, которые порой бывает нелегко "спрятать"
одними лишь средствами разграничения прав доступа к файловым объектам,
существуют еще и такие обекты как /proc и dev/devfs.

При минимизации прав доступа не следует отказываться от использования уже
реализованных в системе механизмов.

Конечно, это не снимает требований к качеству исходного кода самих
сервисов. Но это уже совсем другая история, которая тянет на offtopic для
этого списка рассылки.


--
ldv

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

Re: Re[2]: [sisyphus] chroot

[А.Л. Клютченя]

23 Сентябрь 2002 15:58, Герасимов Дмитрий написал:
> Какой вы Дмитрий, однако, скептический.. :-)..  Хуже не
> будет.. :-)..

	Будет - лишние ресурсы для поддержания этого самого чрута...

-- 
ВсехБлаг!       А. Л. Клютченя
 mail:	asoneofus@kde.ru
 www:	http://www.asoneofus.nm.ru
 icq:	113679387

Re: [sisyphus] chroot

[Anton V. Boyarshinov]

On Mon, 23 Sep 2002 15:06:34 +0400
"Dmitry E. Oboukhov" <node@avanto.mpei.ac.ru> wrote:

> >А также может использовать локальную уязвимость для эскалации
> >своих прав. Что под chroot как правило невозможно.
> >
> почему ?

Потому, что в chroot скорее всего не окажется программ с
локальными уязвимостями. А программы вне chroot изнутри
недоступны. Кроме того, из chroot нельзя даже посмотреть на
системный /etc и многие другие интересные вещи, знать которые
злоумышленнику не надо. Кроме того, исползуемый им exploit может
быть завязан на существование, например /bin/bash. А его там и
нет.

Антон
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
  3:08pm  up 31 days,  7:23,  6 users,  load average: 0.00, 0.01,
0.00

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

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

Re: [sisyphus] chroot

[Dmitry V. Levin]

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

On Mon, Sep 23, 2002 at 03:19:41PM +0400, Dmitry E. Oboukhov wrote:
> >Область рассмотрения (доказательства безопасности) для нечрут сервиса - 
> >вся система.
> >Область рассмотрения для правильно чрутизированного сервиса - область 
> >чрута.
> >
> ладно похоже надо тему закрывать, а то скатываемся опять к началу:
> якобы чрут сужает область рассмотрения. в линукс 2.4 - не сужает.

Вы опять говорите о "руте в чруте", хотя, как мне показалось, эту тему мы
уже закрыли.

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

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


--
ldv

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

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

Anton V. Boyarshinov wrote:

>On Mon, 23 Sep 2002 15:06:34 +0400
>"Dmitry E. Oboukhov" <node@avanto.mpei.ac.ru> wrote:
>
>  
>
>>>А также может использовать локальную уязвимость для эскалации
>>>своих прав. Что под chroot как правило невозможно.
>>>
>>>      
>>>
>>почему ?
>>    
>>
>
>Потому, что в chroot скорее всего не окажется программ с
>локальными уязвимостями. А программы вне chroot изнутри
>недоступны. Кроме того, из chroot нельзя даже посмотреть на
>системный /etc и многие другие интересные вещи, знать которые
>злоумышленнику не надо. Кроме того, исползуемый им exploit может
>быть завязан на существование, например /bin/bash. А его там и
>нет.
>
>Антон
>  
>
то есть ты описываешь мифический случай: ломают одну программу,
потом она _используя_ уязвимость другой ломает всю систему?
бррр
тут слишком имхо невероятная ситуация, ну ладно
принимается

еще аргументы есть ?

Re: [sisyphus] chroot

[Dmitry V. Levin]

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

On Mon, Sep 23, 2002 at 03:32:18PM +0400, Dmitry E. Oboukhov wrote:
> >>>А также может использовать локальную уязвимость для эскалации
> >>>своих прав. Что под chroot как правило невозможно.
> >>>
> >>почему ?
> >
> >Потому, что в chroot скорее всего не окажется программ с
> >локальными уязвимостями. А программы вне chroot изнутри
> >недоступны. Кроме того, из chroot нельзя даже посмотреть на
> >системный /etc и многие другие интересные вещи, знать которые
> >злоумышленнику не надо. Кроме того, исползуемый им exploit может
> >быть завязан на существование, например /bin/bash. А его там и
> >нет.
> >
> то есть ты описываешь мифический случай: ломают одну программу,
> потом она _используя_ уязвимость другой ломает всю систему?

Типовая схема, между прочим.

P.S. Кажется, тема медленно но верно уходит в offtopic.


--
ldv

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

Re[2]: [sisyphus] chroot

[Герасимов Дмитрий]

Hello Dmitry,

Monday, September 23, 2002, 12:56:50 PM, you wrote:

DEO> Dmitry V. Levin wrote:

>>On Mon, Sep 23, 2002 at 01:39:44PM +0400, Dmitry E. Oboukhov wrote:
>>  
>>
>>>почитал, достаточно интересно, однако вопрос остается:
>>>разве разграничение прав не достаточно надежно ?
>>>я так понимаю, что если для каждого приложения завести
>>>пользователя и группу и расставить права доступа
>>>на каталоги и файлы, то можно получить ситуацию ровно
>>>ту же самую: приложение сможет максимум - убить себя,
>>>и то, если оно будет являться владельцем своих файлов.
>>>
>>>При чрутизации конечно можно поменьше думать о правах,
>>>тк файловое пространство все отдано программе.
>>>    
>>>
>>
>>Помещение в chroot позволяет реализовать разграничение доступа более
>>эффективно.
>>
>>  
>>
DEO> "чем армяне лучше чем грузины ? - чем грузины..."
тем что приложение проламывается, получает права рута и поехали
веселится в системе. а когда оно в окружении оно тока в окружении и
навеселится..
DEO> в чем эта большая эффективность ?

DEO> может наоборот меньшая? так как чрут действует расслабляюще (пример с 
DEO> фаерволом
DEO> я выше привел ;)


DEO> _______________________________________________
DEO> Sisyphus mailing list
DEO> Sisyphus@altlinux.ru
DEO> http://altlinux.ru/mailman/listinfo/sisyphus



-- 
Best regards,
 Герасимов                            mailto:matrix@podlipki.ru

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

>
>
>Вы опять говорите о "руте в чруте", хотя, как мне показалось, эту тему мы
>уже закрыли.
>
именно (см ниже)

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

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

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

Re: [sisyphus] chroot

[А.Л. Клютченя]

23 Сентябрь 2002 15:36, Dmitry V. Levin написал:
> P.S. Кажется, тема медленно но верно уходит в offtopic.

	Так и есть :)... Неуж для того чтобы чтото доказать нужно 
совершить противоправные действия? :-)

-- 
ВсехБлаг!       А. Л. Клютченя
 mail:	asoneofus@kde.ru
 www:	http://www.asoneofus.nm.ru
 icq:	113679387

[sisyphus] Re: chroot

[Alexey Tourbin]

On Mon, Sep 23, 2002 at 03:32:18PM +0400, Dmitry E. Oboukhov wrote:
> то есть ты описываешь мифический случай: ломают одну программу,
> потом она _используя_ уязвимость другой ломает всю систему?
> бррр
> тут слишком имхо невероятная ситуация, ну ладно
> принимается

Эта ситуация вовсе не невероятна. Это типичная схема. Проламывается
какой-нибудь сервес, который запущен от пользователя. Теперь в системе
можно исполнять код с правами этого пользователя. В частности, можно
сделать exec* suid-программам. Пример: sudo сейчас в реальных системах
(за которыми не особо следят) бывает дырявым. Раньше со suidperl можно
было выкидывать много фокусов.

Всё дело в том, что в чруте нет suid-программ (это принципиально). Плюс
в чруте нет всего того, что может навести взломщика на ценную мысль.

> еще аргументы есть ?

Это вы нас хотите в чем-то переубедить? Или мы вас? Оставьте.

Re[2]: [sisyphus] chroot

[Герасимов Дмитрий]

Hello Dmitry,

Monday, September 23, 2002, 1:56:48 PM, you wrote:

>>
>>
>>тем что приложение проламывается, получает права рута и поехали
>>веселится в системе. а когда оно в окружении оно тока в окружении и
>>навеселится..
>>  
>>

DEO> Если приложение получает права рута в чруте,
DEO> то спокойно может из под него вылезти... (почитай тред выше)

DEO> а если оно в чруте не работает от рута, то имхо достаточно юниксовой
DEO> системы разграничения прав - тоже не понятно зачем чрут ?

DEO> я предложил обоснование: закрытие _возможно уязвимых мест_, которые
DEO> имеют уязвимости по причине того, что где-то что-то недосмотренно
DEO> (аналог - фаерволы), однако тут есть и недостаток - расслабляющее
DEO> действие на людей: "У нас это работает под чрутом, значит тут все ок" -
DEO> а на самом деле мб не ок ?

Какой вы Дмитрий, однако, скептический.. :-)..  Хуже не будет.. :-)..

-- 
Best regards,
 Герасимов                            mailto:matrix@podlipki.ru

Re: [sisyphus] chroot

[Anton V. Boyarshinov]

On Mon, 23 Sep 2002 15:41:53 +0400
"Dmitry E. Oboukhov" <node@avanto.mpei.ac.ru> wrote:

> один только аргумент: ломают программу, которая _используя
> уязвимость другой_
> получает рута - но это сомнительная польза от чрута (по
> сравнению со вредом от его изпользования)
Не так. Ломают программу, а потом, используя уязвимость другой
(или даже других) получают root. Или даже не получают root, а
закачивают небольшой исходник, компилируют и используют для
распределённых атак или просто как промежутоный пункт для атаки
на другие сервера. Chroot не защищает от проникновения, но
позволяет уменьшить тяжесть последствий.

-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
  3:56pm  up 31 days,  8:11,  6 users,  load average: 0.03, 0.02,
0.00

Re: [sisyphus] Re: chroot

[Dmitry E. Oboukhov]

>
>
>Эта ситуация вовсе не невероятна. Это типичная схема. Проламывается
>какой-нибудь сервес, который запущен от пользователя. Теперь в системе
>можно исполнять код с правами этого пользователя. В частности, можно
>сделать exec* suid-программам. Пример: sudo сейчас в реальных системах
>(за которыми не особо следят) бывает дырявым. Раньше со suidperl можно
>было выкидывать много фокусов.
>
>Всё дело в том, что в чруте нет suid-программ (это принципиально). Плюс
>в чруте нет всего того, что может навести взломщика на ценную мысль.
>  
>
Suid-программы конечно это Suid-программы, но только если в системе 
пользователь
за их счет может получить рута значит, что права где-то неправильно 
поставлены...

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

ладно будем считать тему закрытой, думаю что истина здесь как всегда
где-то посередине. В обоих подходах есть плюсы и минусы. Надеюсь
что в чрутовом подходе здесь использованы только плюсы...

>  
>
>>еще аргументы есть ?
>>    
>>
>
>Это вы нас хотите в чем-то переубедить? Или мы вас? Оставьте.
>
>  
>
все всех ;)

Re[2]: [sisyphus] chroot

[Герасимов Дмитрий]

Hello Dmitry,

Monday, September 23, 2002, 2:07:51 PM, you wrote:

>>
>>
>>DEO> я предложил обоснование: закрытие _возможно уязвимых мест_, которые
>>DEO> имеют уязвимости по причине того, что где-то что-то недосмотренно
>>DEO> (аналог - фаерволы), однако тут есть и недостаток - расслабляющее
>>DEO> действие на людей: "У нас это работает под чрутом, значит тут все ок" -
>>DEO> а на самом деле мб не ок ?
>>
>>Какой вы Дмитрий, однако, скептический.. :-)..  Хуже не будет.. :-)..
>>
>>  
>>

DEO> я как раз и привел чем хуже будет ... ;)
ну разве только в плане самоуспокоения админа.. тут я с вами согласен.
наличие на сервере сетевых демонов в окружении не причина не читать
логи,  не запускать logcheck и chkrootkit.. :-).. кстати жалко, что
последнего нету в Сизифе.. вроде..
DEO> а скептически надо относиться к каждой защите, иначе она не будет защитой

DEO> _______________________________________________
DEO> Sisyphus mailing list
DEO> Sisyphus@altlinux.ru
DEO> http://altlinux.ru/mailman/listinfo/sisyphus



-- 
Best regards,
 Герасимов                            mailto:matrix@podlipki.ru

Re: [sisyphus] chroot

[Dmitry V. Levin]

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

On Mon, Sep 23, 2002 at 03:41:53PM +0400, Dmitry E. Oboukhov wrote:
> рут в чруте - именно он
> если от него нет защиты, следовательно мы должны избавиться от 
> применения рута

Правильно мыслите. :)
Но я об этом уже говорил.

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

Напротив - это очень распротраненная на практике 2-ходовая схема:
1. remote non-root vulnerability дает потенциальному злоумышленнику права
  непривилегированного пользователя в системе.
2. local root vulnerability дает ему права рута.

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

Не только. С помощью chroot jail вы можете обезопасить систему от
зачрутенного сервиса гораздо надежнее, чем без использования чрутизации.
Впрочем, об этом уже было сказано достаточно.


--
ldv

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

Re: [sisyphus] chroot

[Alexey V. Lubimov]

>Если приложение не работает под рутом, то оно может
> повредить только то к чему у нее выставлены права (как впрочем и в 
> случае с чрутом)
> тут плюсов от применения чрута я не вижу.

если просто болтать, то безусловно разницы никакой.
а если попробовать хотя бы накидать планчик ДОКАЗАТЕЛЬСТВА безопасности сервиса для чрут и не чрут окружения, то сразу вылезет разница.

Просто возмите сервис X в системе Y и как увидите неопределенности в каждой строчке, так и прозреете.

А сидючи на завалинке и лузгая семечки такие вопросы не решить...

-- 
С уважением, Алексей Любимов avl@cad.ru

Re: [sisyphus] chroot

[Albert R. Valiev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

В письме от 23 Сентябрь 2002 15:09 Dmitry V. Levin написал:
> В частности, помимо обычных файлов, которые порой бывает нелегко "спрятать"
> одними лишь средствами разграничения прав доступа к файловым объектам,
> существуют еще и такие обекты как /proc и dev/devfs.

вот кстати прикол, от которого у меня мороз по коже прокатился.
а именно:

[darkstar@nklinux darkstar]$ cat /dev/hda2 | grep -a root:

root:$2a$08$VgEG1jlt0nkn//1VgQ8OU.EdKhaO6baq0M9pBUN3ZG2/myPJkhPue:11889::::::
root:$2a$08$VgEG1jlt0nkn//1VgQ8OU.EdKhaO6baq0M9pBUN3ZG2/myPJkhPue:11889::::::
	@(chown root:@nogroup@ $(DESTDIR)$(bindir)/kdesud && chmod 2755  
$(DESTDIR)$(bindir)/kdesud) \
root:
chown root:root /prog/cvsroot/ready/*

и это от обычного пользователя. существует ли способ защиты от такого прикола? 
а то ведь дальше дело совсем простое - сутки-двое на раскодирование...

есть ли способ защиты от этого? 

P.S.

пароль я естественно тут же сменил

- -- 
With Best Regards, Albert R. Valiev
- ------------------------------------
ALT Linux Team [www.altlinux.ru]
KDE Development Team [www.kde.org]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9jwfP7d6wAH+0KuARAnx4AJ91+isb8Yt6Lg4r0pH2dAeAlonWhACgobr8
Ay43V4VGG1GMWBZpgR3MuTA=
=tkpx
-----END PGP SIGNATURE-----

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

>
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>В письме от 23 Сентябрь 2002 15:09 Dmitry V. Levin написал:
>  
>
>>В частности, помимо обычных файлов, которые порой бывает нелегко "спрятать"
>>одними лишь средствами разграничения прав доступа к файловым объектам,
>>существуют еще и такие обекты как /proc и dev/devfs.
>>    
>>
>
>вот кстати прикол, от которого у меня мороз по коже прокатился.
>а именно:
>
>[darkstar@nklinux darkstar]$ cat /dev/hda2 | grep -a root:
>
>root:$2a$08$VgEG1jlt0nkn//1VgQ8OU.EdKhaO6baq0M9pBUN3ZG2/myPJkhPue:11889::::::
>root:$2a$08$VgEG1jlt0nkn//1VgQ8OU.EdKhaO6baq0M9pBUN3ZG2/myPJkhPue:11889::::::
>	@(chown root:@nogroup@ $(DESTDIR)$(bindir)/kdesud && chmod 2755  
>$(DESTDIR)$(bindir)/kdesud) \
>root:
>chown root:root /prog/cvsroot/ready/*
>

[/home/dimka]$ cat /dev/hda1 |grep -a root
cat: /dev/hda1: Permission denied

так что выставляй права доступа на девайсы ;)

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

Albert R. Valiev wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>В письме от 23 Сентябрь 2002 15:09 Dmitry V. Levin написал:
>  
>
>>В частности, помимо обычных файлов, которые порой бывает нелегко "спрятать"
>>одними лишь средствами разграничения прав доступа к файловым объектам,
>>существуют еще и такие обекты как /proc и dev/devfs.
>>    
>>
>
>вот кстати прикол, от которого у меня мороз по коже прокатился.
>а именно:
>
>[darkstar@nklinux darkstar]$ cat /dev/hda2 | grep -a root:
>
>root:$2a$08$VgEG1jlt0nkn//1VgQ8OU.EdKhaO6baq0M9pBUN3ZG2/myPJkhPue:11889::::::
>root:$2a$08$VgEG1jlt0nkn//1VgQ8OU.EdKhaO6baq0M9pBUN3ZG2/myPJkhPue:11889::::::
>	@(chown root:@nogroup@ $(DESTDIR)$(bindir)/kdesud && chmod 2755  
>$(DESTDIR)$(bindir)/kdesud) \
>root:
>chown root:root /prog/cvsroot/ready/*
>
>и это от обычного пользователя. существует ли способ защиты от такого прикола? 
>а то ведь дальше дело совсем простое - сутки-двое на раскодирование...
>
>есть ли способ защиты от этого? 
>
>  
>
в мастере (если это мастер) право читать (и писать) будут иметь 
пользователи из группы
disk
так что смотри свой /etc/group

Re: [sisyphus] chroot

[Dmitry V. Levin]

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

On Mon, Sep 23, 2002 at 04:39:03PM +0400, Dmitry E. Oboukhov wrote:
> >вот кстати прикол, от которого у меня мороз по коже прокатился.
> >а именно:
> >
> >[darkstar@nklinux darkstar]$ cat /dev/hda2 | grep -a root:
> >
> >root:$2a$08$VgEG1jlt0nkn//1VgQ8OU.EdKhaO6baq0M9pBUN3ZG2/myPJkhPue:11889::::::
> >root:$2a$08$VgEG1jlt0nkn//1VgQ8OU.EdKhaO6baq0M9pBUN3ZG2/myPJkhPue:11889::::::
> >	@(chown root:@nogroup@ $(DESTDIR)$(bindir)/kdesud && chmod 2755  
> >$(DESTDIR)$(bindir)/kdesud) \
> >root:
> >chown root:root /prog/cvsroot/ready/*
> 
> [/home/dimka]$ cat /dev/hda1 |grep -a root
> cat: /dev/hda1: Permission denied
> 
> так что выставляй права доступа на девайсы ;)

$ cat /dev/hda2
cat: /dev/hda2: No such file or directory

Так что chroot rulez! :-)


--
ldv

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

Re: [sisyphus] chroot

[Albert R. Valiev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

В письме от 23 Сентябрь 2002 16:39 Dmitry E. Oboukhov написал:
> [/home/dimka]$ cat /dev/hda1 |grep -a root
> cat: /dev/hda1: Permission denied
>
> так что выставляй права доступа на девайсы ;)
хмммм это уже становится интересным. сейчас посмотрю


- -- 
With Best Regards, Albert R. Valiev
- ------------------------------------
ALT Linux Team [www.altlinux.ru]
KDE Development Team [www.kde.org]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9jwz27d6wAH+0KuARArurAKD1+zAbPmtAprR1JFcoYLlNnFyGwwCglQYC
cKodt3Jda4B9JwkCqOana+k=
=bTx5
-----END PGP SIGNATURE-----

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

>
>
>$ cat /dev/hda2
>cat: /dev/hda2: No such file or directory
>
>Так что chroot rulez! :-)
>
>  
>

ну и причем тут чрут ?
Я вроде уже объяснил человеку в чем дело...
группа disk
/etc/group

он наверно когда мастер ставил - подобавлял себя во все группы без 
разбора...

так что не чрут - рулез, а чмод - рулез!

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

Dmitry E. Oboukhov wrote:

>>
>>
>> $ cat /dev/hda2
>> cat: /dev/hda2: No such file or directory
>>
>> Так что chroot rulez! :-)
>>
>>  
>>
>
> ну и причем тут чрут ?
> Я вроде уже объяснил человеку в чем дело...
> группа disk
> /etc/group
>
> он наверно когда мастер ставил - подобавлял себя во все группы без 
> разбора...
>
> так что не чрут - рулез, а чмод - рулез!

мало того, если он еще от юзера скажет
dd if=/dev/zero of=/dev/hda
то получит очень интересный результат, потому
как на группа disk имеет права и на запись тоже :(((

Re: [sisyphus] chroot

[Albert R. Valiev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

В письме от 23 Сентябрь 2002 16:41 Dmitry E. Oboukhov написал:
> >есть ли способ защиты от этого?
> в мастере (если это мастер) право читать (и писать) будут иметь
> пользователи из группы
> disk
> так что смотри свой /etc/group

у меня сизиф стоит с момента появления на свет первой беты spring 2001. (и 
собственно apt-get). 

а вот откуда появились такие права, это еще надо посмотреть. переустановка 
пакета dev решила проблему, однако это мне не по душе. 

- -- 
With Best Regards, Albert R. Valiev
- ------------------------------------
ALT Linux Team [www.altlinux.ru]
KDE Development Team [www.kde.org]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9jxTb7d6wAH+0KuARAlVGAKCeKCr9jSJ+fEnj6gqT0iouu7e0rgCgjagE
IzY2InJD+0QAkFPFW8tqpOM=
=acTz
-----END PGP SIGNATURE-----

Re: [sisyphus] chroot

[Albert R. Valiev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

В письме от 23 Сентябрь 2002 16:49 Dmitry E. Oboukhov написал:
> он наверно когда мастер ставил - подобавлял себя во все группы без
> разбора...
мой пользователь является членом только трех груп - одлна одноименная, другая 
sysusers, собственно мною же добавленная, третья - rpm. 

и кстати, в мастере по умолчанию все в порядке. а накосячил с правами я сам 
(только что histrory просмотрел :((( ). увы уже не вспомню, зачем мне 666 на 
/dev/hda* понадобился. Кстати, в этом отношении devfs рульнее, т.к. дерево 
/dev/ создается каждый раз заново. 

Дмитрий, может добавить в скрипт проверки безопасности  проверку на права в 
/dev/ для порядку? 


- -- 
With Best Regards, Albert R. Valiev
- ------------------------------------
ALT Linux Team [www.altlinux.ru]
KDE Development Team [www.kde.org]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9jxYs7d6wAH+0KuARAsZeAKD1oN1xJVRcwWzI+jBzdCrme/jszACglZwi
8PBCOiwJ1OCyhWp+H2k+0MA=
=OgNy
-----END PGP SIGNATURE-----

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

Albert R. Valiev wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>В письме от 23 Сентябрь 2002 16:41 Dmitry E. Oboukhov написал:
>  
>
>>>есть ли способ защиты от этого?
>>>      
>>>
>>в мастере (если это мастер) право читать (и писать) будут иметь
>>пользователи из группы
>>disk
>>так что смотри свой /etc/group
>>    
>>
>
>у меня сизиф стоит с момента появления на свет первой беты spring 2001. (и 
>собственно apt-get). 
>
>а вот откуда появились такие права, это еще надо посмотреть. переустановка 
>пакета dev решила проблему, однако это мне не по душе. 
>
>  
>
а чего в группе disk ? был прописан, или права на /dev/hda 666 стояли ?
если давно ставил систему, то конечно в сизифе могло что-то и смениться
да система РПМ не переустановила права хез короче...

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

Albert R. Valiev wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>В письме от 23 Сентябрь 2002 16:49 Dmitry E. Oboukhov написал:
>  
>
>>он наверно когда мастер ставил - подобавлял себя во все группы без
>>разбора...
>>    
>>
>мой пользователь является членом только трех груп - одлна одноименная, другая 
>sysusers, собственно мною же добавленная, третья - rpm. 
>
>и кстати, в мастере по умолчанию все в порядке. а накосячил с правами я сам 
>(только что histrory просмотрел :((( ). увы уже не вспомню, зачем мне 666 на 
>/dev/hda* понадобился. Кстати, в этом отношении devfs рульнее, т.к. дерево 
>/dev/ создается каждый раз заново. 
>
>Дмитрий, может добавить в скрипт проверки безопасности  проверку на права в 
>/dev/ для порядку? 
>
>  
>
я думаю просто надо всегда фиксировать то, что ты делаешь в системе под 
рутом,
иначе не напасешься скриптов на проверки - а не открылось ли тут чего 
или там...
хотя мастеровский скрипт производящий проверку каталога /bin мне нравится,
напиши АЕНу - может он добавит в него чекинг и /dev/ каталога, а пока 
можешь и
сам это сделать....

[sisyphus] Re: chroot

[Michael Shigorin]

On Mon, Sep 23, 2002 at 02:56:48PM +0400, Dmitry E. Oboukhov wrote:
> Если приложение получает права рута в чруте,
> то спокойно может из под него вылезти... (почитай тред выше)

выше я доказательства не нашел, в багтраке тоже не припомню.  Это
я не к тому, что /sd вроде как все же сделал 2.4-ow и кое-где в
округе его раздают в штатном ядре (создавая проблемы
пользователям wine ;-) -- и что я "против" видеть в нашем -smp.

> а если оно в чруте не работает от рута, то имхо достаточно юниксовой
> системы разграничения прав - тоже не понятно зачем чрут ?

потому как есть world readable objects

> однако тут есть и недостаток - расслабляющее

этого кодом не вылечить.

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

[sisyphus] Re: chroot

[Michael Shigorin]

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

On Mon, Sep 23, 2002 at 03:10:46PM +0300, Герасимов Дмитрий wrote:
> не причина не читать логи,  не запускать logcheck и

причем именно с helper'ами это хотя бы реально...

> chkrootkit.. :-).. кстати жалко, что последнего нету в Сизифе..

ну так в чем проблема? ;)

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

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

[sisyphus] Re: chroot

[Michael Shigorin]

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

On Mon, Sep 23, 2002 at 04:03:59PM +0400, Dmitry E. Oboukhov wrote:
> эта тема родилась от того, что разговаривал я тут с одним
> знакомым админом, он кастл (по моему) у себя держит, и считает
> что сломать его невозможно только от применения повсеместного
> чрута.

Это его личная некомпетентность.

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

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

Re: [sisyphus] Re: chroot

[Dmitry E. Oboukhov]

Michael Shigorin wrote:

>On Mon, Sep 23, 2002 at 02:56:48PM +0400, Dmitry E. Oboukhov wrote:
>  
>
>>Если приложение получает права рута в чруте,
>>то спокойно может из под него вылезти... (почитай тред выше)
>>    
>>
>
>выше я доказательства не нашел, в багтраке тоже не припомню.  
>
о доказателствах никто не говорил
говорилось о возможности
выше я привел ссылку на описание алгоритма здесь же в рассылке....
урл пока не нашел - но дома посмотрю
но смысл один и тот-же (- поглядите письмо ASA)
- повторное монтирование корневого каталога себе в
чрутовый и (не обязательно) новый чрут в него...

>Это
>я не к тому, что /sd вроде как все же сделал 2.4-ow и кое-где в
>округе его раздают в штатном ядре (создавая проблемы
>пользователям wine ;-) -- и что я "против" видеть в нашем -smp.
>
>  
>
>>а если оно в чруте не работает от рута, то имхо достаточно юниксовой
>>системы разграничения прав - тоже не понятно зачем чрут ?
>>    
>>
>
>потому как есть world readable objects
>
права - права
и чрут тут не причем...

>
>  
>
>>однако тут есть и недостаток - расслабляющее
>>    
>>
>
>этого кодом не вылечить.
>
представьте, что нет понятия фаервол - как тогда все бы тщательно 
настраивали
доступ к своим серверам ?

Re: [sisyphus] Re: chroot

[Dmitry V. Levin]

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

On Mon, Sep 23, 2002 at 06:19:02PM +0400, Dmitry E. Oboukhov wrote:
> >>Если приложение получает права рута в чруте,
> >>то спокойно может из под него вылезти... (почитай тред выше)
> >
> >выше я доказательства не нашел, в багтраке тоже не припомню.  
> >
> о доказателствах никто не говорил
> говорилось о возможности
> выше я привел ссылку на описание алгоритма здесь же в рассылке....
> урл пока не нашел - но дома посмотрю
> но смысл один и тот-же (- поглядите письмо ASA)
> - повторное монтирование корневого каталога себе в
> чрутовый и (не обязательно) новый чрут в него...

Привилегированный процесс (euid==0) обладает таким БОЛЬШИМ количеством
способов выйти из chroot jail, что об этом даже говорить не интересно.


--
ldv

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

Re: [sisyphus] chroot

[AHTOH]

23 Сентябрь 2002 16:01, Anton V. Boyarshinov написал:
> On Mon, 23 Sep 2002 15:41:53 +0400

> Не так. Ломают программу, а потом, используя уязвимость другой
> (или даже других) получают root. Или даже не получают root, а
> закачивают небольшой исходник, компилируют и используют для
> распределённых атак или просто как промежутоный пункт для
> атаки на другие сервера. Chroot не защищает от проникновения,
> но позволяет уменьшить тяжесть последствий.

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

Мне не дает покоя вопрос почему вообще не запретят под root 
делать некторые операции, например удалять файлы или 
модифицировать их или записывать в определенные места без
исполнения под root определенных действий или ввода пароля.

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

Мне, например, не нравиться, что если на файле с root:root стоит 
r--r--r--(0444), то все равно root может модифицировать такой 
файл не обращая внимание на read_only.

-- 
Антон, SET RI

Re: [sisyphus] chroot

[Герасимов Дмитрий]

On Mon, 23 Sep 2002 22:05:04 +0400
AHTOH <ahtoh2@lensoveta.spb.ru> wrote:

> 23 Сентябрь 2002 16:01, Anton V. Boyarshinov написал:
> > On Mon, 23 Sep 2002 15:41:53 +0400
> 
> > Не так. Ломают программу, а потом, используя уязвимость другой
> > (или даже других) получают root. Или даже не получают root, а
> > закачивают небольшой исходник, компилируют и используют для
> > распределённых атак или просто как промежутоный пункт для
> > атаки на другие сервера. Chroot не защищает от проникновения,
> > но позволяет уменьшить тяжесть последствий.
> 
> Ну, да. Хотя гораздо хуже, когда утечет важная информация или 
> сотрут важные файлы, а пластдарм все же тебя _лично_ касается 
> меньше, но тоже плохо.
> 
> Мне не дает покоя вопрос почему вообще не запретят под root 
> делать некторые операции, например удалять файлы или 
> модифицировать их или записывать в определенные места без
> исполнения под root определенных действий или ввода пароля.
> 
> Слашыл, что такая система есть ввиде патчей к ядру, но ее 
> почему-то не применяют в ALTLinux. Возможно это добавит больше 
> проблем пользователю. Ведь известно, что усиление безопастности 
> обратно пропорциаонально простоте работы.
> 
> Мне, например, не нравиться, что если на файле с root:root стоит 
> r--r--r--(0444), то все равно root может модифицировать такой 
> файл не обращая внимание на read_only.
chattr не спасет отца русской демократии?
> 
> -- 
> Антон, SET RI
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@altlinux.ru
> http://altlinux.ru/mailman/listinfo/sisyphus


-- 
--------------------------
JID:	q2digger@jabber.ru 
ICQ:	26277841
e-mail: matrix@podlipki.ru
--------------------------

Re: [sisyphus] chroot

["Алексей Любимов"]

> Слашыл, что такая система есть ввиде патчей к ядру, но ее 
> почему-то не применяют в ALTLinux.
lids
rsbac
вторая есть альте и позволяет внедрить разделение обязанностей по надзору и исполнению.

> Возможно это добавит больше 
> проблем пользователю. Ведь известно, что усиление безопастности 
> обратно пропорциаонально простоте работы.

громадный объем работы по обработке приложений и еще больший по обработке пользователей.
см castle
-- 
Любимов Алексей
avl@l14.ru

Re: [sisyphus] chroot

[AHTOH]

23 Сентябрь 2002 22:13, Герасимов Дмитрий написал:

> > Мне, например, не нравиться, что если на файле с root:root
> > стоит r--r--r--(0444), то все равно root может
> > модифицировать такой файл не обращая внимание на read_only.
>
> chattr не спасет отца русской демократии?

Можно, но не очень удобно.
Ну, если стоит на файле read_only почему его можно удалять? Не 
логично.

Права rw-r-r и r-r-r для root одно и тоже. Ну, это не правильно.

-- 
Антон, SET RI

Re: [sisyphus] chroot

[Igor Homyakov]

On Mon, Sep 23, 2002 at 11:01:15PM +0400, AHTOH wrote:
> 23 Сентябрь 2002 22:13, Герасимов Дмитрий написал:

> > > Мне, например, не нравиться, что если на файле с root:root
> > > стоит r--r--r--(0444), то все равно root может
> > > модифицировать такой файл не обращая внимание на read_only.
> >
> > chattr не спасет отца русской демократии?

> Можно, но не очень удобно.
> Ну, если стоит на файле read_only почему его можно удалять? Не 
> логично.

> Права rw-r-r и r-r-r для root одно и тоже. Ну, это не правильно.

Это правильно. Алгоритм проверки прав доступа всегда один и тот же:
Если root (uid=0) -- доступ разрешен, в противном случе проверяються
права доступа, т.е для root вообще пермиссии "не работают". 
 
--
Igor Homyakov
<homyakov at altlinux dot ru>
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=190141

Re: [sisyphus] chroot

[AHTOH]

24 Сентябрь 2002 00:38, Igor Homyakov написал:

> Это правильно. Алгоритм проверки прав доступа всегда один и
> тот же: Если root (uid=0) -- доступ разрешен, в противном
> случе проверяються права доступа, т.е для root вообще
> пермиссии "не работают".

Вот это мне и не нравиться.
По-моему, как Unix разработали в конце 70х так в этой области 
больше ничего и не меняли.
А где ж развитие?
Можно например сделать, чтобы некоторые файлы вообще получать 
по-паролю, шифрование и прочие вещи на уровне fs, компрессия и 
т.д.
Доп. атрибуты и всякое-такое. 
Но, я уверен, что никто этим заниматься не будет.
Наверное никому не нужно.
А все же root в правах я бы ограничил.

P.S.
По-моему Linux развиватся только в сторону поддержки новых 
железяк и все.

-- 
Антон, SET RI

Re: [sisyphus] chroot

[Igor Homyakov]

On Tue, Sep 24, 2002 at 02:07:28AM +0400, AHTOH wrote:
> 24 Сентябрь 2002 00:38, Igor Homyakov написал:

> > Это правильно. Алгоритм проверки прав доступа всегда один и
> > тот же: Если root (uid=0) -- доступ разрешен, в противном
> > случе проверяються права доступа, т.е для root вообще
> > пермиссии "не работают".

> Вот это мне и не нравиться.
> По-моему, как Unix разработали в конце 70х так в этой области 
> больше ничего и не меняли.
> А где ж развитие?

"Стабильность - показатель класса" если за всё это время
ничего не было изменено значит изначально всё было сделано правильно.
В этом смысле показательна история развития Solaris, изменялось
только реализация ("нутро" если хотите), все базовые принципы
остались. 

Keep It Simple ...

> Можно например сделать, чтобы некоторые файлы вообще получать 
> по-паролю, шифрование и прочие вещи на уровне fs, компрессия и 

Всё это есть

> т.д.
> Доп. атрибуты и всякое-такое. 
> Но, я уверен, что никто этим заниматься не будет.
> Наверное никому не нужно.
> А все же root в правах я бы ограничил.

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

В ACL (не говоря уже о RSBAC) нет необходимости в 90-95 % случаев.

--
Igor Homyakov
<homyakov at altlinux dot ru>
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=190141

Re[2]: [sisyphus] chroot

[Герасимов Дмитрий]

Hello Igor,

Monday, September 23, 2002, 11:38:38 PM, you wrote:

IH> On Mon, Sep 23, 2002 at 11:01:15PM +0400, AHTOH wrote:
>> 23 Сентябрь 2002 22:13, Герасимов Дмитрий написал:

>> > > Мне, например, не нравиться, что если на файле с root:root
>> > > стоит r--r--r--(0444), то все равно root может
>> > > модифицировать такой файл не обращая внимание на read_only.
>> >
>> > chattr не спасет отца русской демократии?

>> Можно, но не очень удобно.
>> Ну, если стоит на файле read_only почему его можно удалять? Не 
>> логично.

>> Права rw-r-r и r-r-r для root одно и тоже. Ну, это не правильно.

IH> Это правильно. Алгоритм проверки прав доступа всегда один и тот же:
IH> Если root (uid=0) -- доступ разрешен, в противном случе проверяються
IH> права доступа, т.е для root вообще пермиссии "не работают". 
на то он и рут - суперпользователь.



-- 
Best regards,
 Герасимов                            mailto:matrix@podlipki.ru

Re[2]: [sisyphus] chroot

[Герасимов Дмитрий]

Hello AHTOH,

Tuesday, September 24, 2002, 1:07:28 AM, you wrote:

A> 24 Сентябрь 2002 00:38, Igor Homyakov написал:

>> Это правильно. Алгоритм проверки прав доступа всегда один и
>> тот же: Если root (uid=0) -- доступ разрешен, в противном
>> случе проверяються права доступа, т.е для root вообще
>> пермиссии "не работают".

A> Вот это мне и не нравиться.
A> По-моему, как Unix разработали в конце 70х так в этой области 
A> больше ничего и не меняли.
A> А где ж развитие?
A> Можно например сделать, чтобы некоторые файлы вообще получать 
A> по-паролю, шифрование и прочие вещи на уровне fs, компрессия и 
A> т.д.
A> Доп. атрибуты и всякое-такое. 
A> Но, я уверен, что никто этим заниматься не будет.
A> Наверное никому не нужно.
A> А все же root в правах я бы ограничил.

A> P.S.
A> По-моему Linux развиватся только в сторону поддержки новых 
A> железяк и все.
Антон, а вы про RSBAC слышали?.. там рут совсемммм не главный..
поставьте, настройте, запротоколируйте телодвижения.. нам расскажите,
тут многим интересно будет..
права там мнооого на что проверяются..



-- 
Best regards,
 Герасимов                            mailto:matrix@podlipki.ru

Re: [sisyphus] Re: chroot

[Anton V. Boyarshinov]

On Mon, 23 Sep 2002 18:19:02 +0400
"Dmitry E. Oboukhov" <node@avanto.mpei.ac.ru> wrote:
>> потому как есть world readable objects
> права - права
> и чрут тут не причем...
Причем тут права? Многие объекты *не могут* не быть  world
readable!
например: /etc/passwd /etc/resolv.conf и ещё очень много
интересного.


> представьте, что нет понятия фаервол - как тогда все бы
> тщательно настраивали
> доступ к своим серверам ?
А также к рабчим станциям. И к сетевым принтерам. И нельзя было
бы сделать внутренний web сервер с конфеденциальной информацией
открытым без пароля в закрытой сети. И вообще работы бы стало
больше, а безопасность -- хуже.

Антон
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 10:16am  up 32 days,  2:31,  6 users,  load average: 0.00, 0.00,
0.05

Re: [sisyphus] Re: chroot

[Dmitry E. Oboukhov]

>
>
>>представьте, что нет понятия фаервол - как тогда все бы
>>тщательно настраивали
>>доступ к своим серверам ?
>>    
>>
>А также к рабчим станциям. И к сетевым принтерам. И нельзя было
>бы сделать внутренний web сервер с конфеденциальной информацией
>открытым без пароля в закрытой сети. И вообще работы бы стало
>больше, а безопасность -- хуже.
>  
>
в том то и дело, что безопасность без фаервола _можно_ сделать не хуже,
просто труднее - так как надо не в одном месте настраивать, а везде и все.

Re: [sisyphus] Re: chroot

[Anton V. Boyarshinov]

On Tue, 24 Sep 2002 12:09:48 +0400
"Dmitry E. Oboukhov" <node@avanto.mpei.ac.ru> wrote:

> в том то и дело, что безопасность без фаервола _можно_ сделать
> не хуже, просто труднее - так как надо не в одном месте
> настраивать, а везде и все.
Нельзя. Сама необходимость настраиваить в бОльшем числе мест
понижает безопасность.

Антон
PS Всё, всё, я закругляюсь с этим оффтопиком.
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 12:16pm  up 32 days,  4:31,  6 users,  load average: 0.01, 0.33,
0.37

Re: [sisyphus] chroot

[aen]

AHTOH wrote:

>24 Сентябрь 2002 00:38, Igor Homyakov написал:
>
>  
>
>>Это правильно. Алгоритм проверки прав доступа всегда один и
>>тот же: Если root (uid=0) -- доступ разрешен, в противном
>>случе проверяються права доступа, т.е для root вообще
>>пермиссии "не работают".
>>    
>>
>
>Вот это мне и не нравиться.
>По-моему, как Unix разработали в конце 70х так в этой области 
>больше ничего и не меняли.
>А где ж развитие?
>Можно например сделать, чтобы некоторые файлы вообще получать 
>по-паролю, шифрование и прочие вещи на уровне fs, компрессия и 
>т.д.
>Доп. атрибуты и всякое-такое. 
>Но, я уверен, что никто этим заниматься не будет.
>Наверное никому не нужно.
>
Да занимаются  этим, занимаются.
В частности -- inger@altlinux.ru, один из разработчиков RSBAC 
(http://www.rsbac.org).
Castle  beta3 уже не новый, но составить представление можно.
И нужно это -- очень, но и сложно изрядно.

Rgrds, AEN

[sisyphus] Re: chroot

[Michael Shigorin]

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

On Mon, Sep 23, 2002 at 11:01:15PM +0400, AHTOH wrote:
> Ну, если стоит на файле read_only почему его можно удалять? Не
> логично.

Потому как удаление (в т.ч.) регулируется perms на каталог,
содержащий файл.

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

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

Re[2]: [sisyphus] chroot

[Борис Ревякин]

Здравствуйте, AHTOH.

Вы писали 24 сентября 2002 г., 2:07:28:

A> 24 Сентябрь 2002 00:38, Igor Homyakov написал:

>> Это правильно. Алгоритм проверки прав доступа всегда один и
>> тот же: Если root (uid=0) -- доступ разрешен, в противном
>> случе проверяються права доступа, т.е для root вообще
>> пермиссии "не работают".

A> Вот это мне и не нравиться.
A> По-моему, как Unix разработали в конце 70х так в этой области 
A> больше ничего и не меняли.
A> А где ж развитие?
A> Можно например сделать, чтобы некоторые файлы вообще получать 
A> по-паролю, шифрование и прочие вещи на уровне fs, компрессия и 
A> т.д.
A> Доп. атрибуты и всякое-такое. 
A> Но, я уверен, что никто этим заниматься не будет.
A> Наверное никому не нужно.
A> А все же root в правах я бы ограничил.

A> P.S.
A> По-моему Linux развиватся только в сторону поддержки новых 
A> железяк и все.


Ну батенька, тогда вам надо в команду EROS перебираться. :)

-- 
С уважением,
 Борис                          mailto:br@gin.ru

Re: [sisyphus] chroot

[AHTOH]

24 Сентябрь 2002 08:45, Igor Homyakov написал:
> On Tue, Sep 24, 2002 at 02:07:28AM +0400, AHTOH wrote:

> "Стабильность - показатель класса" если за всё это время
> ничего не было изменено значит изначально всё было сделано
> правильно. В этом смысле показательна история развития
> Solaris, изменялось только реализация ("нутро" если хотите),
> все базовые принципы остались.

А в Винде (w9x) было что-то изменено в этой области?
Это показатель чего?

> Для начала решите достаточно ли Вы разбираетесь в происходящем
> чтобы делать такие заявления ? Не обижайтесь, просто решите
> этот вопрос для себя. Потому что если это осознаная
> необходимость это одно а если желание "наворотов" или чтобы
> было как у других это совсем другое.

Во первых раньше под Linux вирусов не было вообще.
Во вторых не было червей и такого распространения инета.
В 3. Ошибки и дыры в программах будут всегда. Тем более в наше 
быстроее время.
В 4. Бурное развитие программных  и аппаратных технологий. 
(Нельзя же стоять на месте)
Не могли разработчики Денис Риттчи и Томсон продумать все "до 
самых кончиков". Они писали систему для своего времени, а сейчас 
время поменялось и ситуация тоже.

> В ACL (не говоря уже о RSBAC) нет необходимости в 90-95 %
> случаев.

Если бы это у меня было, я бы этим воспользовался.
Почему никто из вас не работает под root?
Чего-то боитесь? Ведь в 90-95% случаев ничего скорее всего не 
случиться. Я первых год работы в Unix работал только под root и 
по-другому не умел и ничего ж не случалось. Однко ж...

Вот если кто-то узнает пароль root. Он что же теперь может 
сделать все что захочет? Когда все зависит от одного элемента 
это признак не надежной системы. Это одно валиться и все 
валиться.

Обычно "нет необходимости" говорят тогда, когда чего-то нет.
А когда появляется это что-то, то говорят как это здорово что это 
что-то есть и как мы раньше без этого что-то жили непонятно.

-- 
Антон, SET RI

Re: [sisyphus] chroot

[Vitaly Lipatov]

On 23 Сентябрь 2002 23:01, AHTOH wrote:
> 23 Сентябрь 2002 22:13, Герасимов Дмитрий написал:
> > > Мне, например, не нравиться, что если на файле с root:root
> > > стоит r--r--r--(0444), то все равно root может
> > > модифицировать такой файл не обращая внимание на
> > > read_only.
> >
> > chattr не спасет отца русской демократии?
>
> Можно, но не очень удобно.
> Ну, если стоит на файле read_only почему его можно удалять? Не
> логично.
Для этого нужно поставить ro на каталог (или SUID-бит на 
каталог), а ro файла тут ни при чём.

>
> Права rw-r-r и r-r-r для root одно и тоже. Ну, это не
> правильно.

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux! LaTeX! LyX!

Re: [sisyphus] chroot

[Alexey V. Lubimov]

> Во первых раньше под Linux вирусов не было вообще.

линукс совместим с юниксовыми вирусами, так что вирусы под линукс были
раньше, чем он повился на свет :)

> Во вторых не было червей и такого распространения инета.

линукс по жизни стоит в сети на серверах. так что черви и интернет для
линукса гораздо актуальнее, чем для "более других ОС"

> В 3. Ошибки и дыры в программах будут всегда. Тем более в наше 
> быстроее время.

ессно.

> В 4. Бурное развитие программных  и аппаратных технологий. 
> (Нельзя же стоять на месте)
> Не могли разработчики Денис Риттчи и Томсон продумать все "до 
> самых кончиков". Они писали систему для своего времени, а сейчас 
> время поменялось и ситуация тоже.

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


> > В ACL (не говоря уже о RSBAC) нет необходимости в 90-95 %
> > случаев.
> 
> Если бы это у меня было, я бы этим воспользовался.

apt-get install libacl ставим линукс на XFS (давно уже только на него и
ставлю)и пользуемся...

> Почему никто из вас не работает под root?
> Чего-то боитесь? Ведь в 90-95% случаев ничего скорее всего не 
> случиться. Я первых год работы в Unix работал только под root и 
> по-другому не умел и ничего ж не случалось. Однко ж...

случится. от ошибок не застрахован никто. это удобно.

> 
> Вот если кто-то узнает пароль root. Он что же теперь может 
> сделать все что захочет? Когда все зависит от одного элемента 
> это признак не надежной системы. Это одно валиться и все 
> валиться.

Эти претензии уже давно озвучены и не только в ОС.
Поэтому уже давно есть attr и есть разработки, в которых роль root
ограничена или даже введена еще одна роль - офицера безопасности.

Вам стоит просто вылезти из песочницы и почитать про эти вещи, а потом
поставить castle и посмотреть на это дело в действии.


> Обычно "нет необходимости" говорят тогда, когда чего-то нет.
> А когда появляется это что-то, то говорят как это здорово что это 
> что-то есть и как мы раньше без этого что-то жили непонятно.

Ничего не бывает бесплатно. В виндозе есть ACL, но правда жизни состоит
в том, что народ работает под администратором, потому что ему тяжело
пользоваться этим механизмом. В линуксе давно уже есть и ACL и гораздо
более интересные вещи, но чтобы их внедрить к себе, нужно приложить
немало усилий, а в 95% случаев полученные плюсы не оправдают этих
усилий.

-- 
С уважением, Алексей Любимов avl@cad.ru

Re: [sisyphus] chroot

[AHTOH]

25 Сентябрь 2002 16:30, Alexey V. Lubimov написал:

> Ничего не бывает бесплатно. В виндозе есть ACL, но правда
> жизни состоит в том, что народ работает под администратором,
> потому что ему тяжело пользоваться этим механизмом.

Кто в Linux работает под root?
Это тоже в некотором смысле не удобно, однко же привыкли.

_Сегодня_ механизм должен быть и надежным и простым в 
использовании, тогда только есть в нем какой-то смысл.
Как совместить эти не совместимые вещи не моя задача.
Если механизм есть, а им сложно и не удобно пользоваться, значит 
считайте что для большинства его нет. Так и надо говорить.
Сегодня != вчера.

 В линуксе
> давно уже есть и ACL и гораздо более интересные вещи, но чтобы
> их внедрить к себе, нужно приложить немало усилий, а в 95%
> случаев полученные плюсы не оправдают этих усилий.

Почему бы не внедрить это сразу в дистрибутиве (Sisyphus)?
Я конечно сам не буду этим заниматься, потому что и времени нет и
смысла. А вот если бы это сразу поставили и настроили вот 
тогда... :) ...было бы здорово.

-- 
Антон, SET RI

Re: [sisyphus] chroot

[AHTOH]

25 Сентябрь 2002 01:26, Vitaly Lipatov написал:

> Для этого нужно поставить ro на каталог (или SUID-бит на
> каталог), а ro файла тут ни при чём.

Если на файле стоит для меня ro я не могу в него записать.
А под root могу. Под root я все могу. А чем он лучше? Тем что у 
него uid 0?

rm -R * запустить в корне случайно и... потому что root!

-- 
Антон, SET RI

Re: [sisyphus] chroot

["Алексей Любимов"]

> > Ничего не бывает бесплатно. В виндозе есть ACL, но правда
> > жизни состоит в том, что народ работает под администратором,
> > потому что ему тяжело пользоваться этим механизмом.
> 
> Кто в Linux работает под root?
потому что это просто и эффективно, потому и не работают.
отчасти потому что нет acl в повседневной жизни.

> Это тоже в некотором смысле не удобно, однко же привыкли.

это _очень_ удобно.
в отличии от геморроя с ведением списков acl.
ls -l и сразу видно, кому и что позволено. 
просто вывести aclы в таком виде не получиться.

> 
> _Сегодня_ механизм должен быть и надежным и простым в 
> использовании, тогда только есть в нем какой-то смысл.
> Как совместить эти не совместимые вещи не моя задача.

а чья?

> Если механизм есть, а им сложно и не удобно пользоваться, значит 
> считайте что для большинства его нет. Так и надо говорить.
> Сегодня != вчера.

так и говорим, что в линуксе есть распределение прав и полномочий, а в другой ОС нет...

> 
>  В линуксе
> > давно уже есть и ACL и гораздо более интересные вещи, но чтобы
> > их внедрить к себе, нужно приложить немало усилий, а в 95%
> > случаев полученные плюсы не оправдают этих усилий.
> 
> Почему бы не внедрить это сразу в дистрибутиве (Sisyphus)?

придется перетачивать тонну приложений, которые считают, что рут может все.
в castle это сделали для ограниченного серверного набора приложений.

> Я конечно сам не буду этим заниматься, потому что и времени нет и
> смысла.
вот все так и говорят.

> А вот если бы это сразу поставили и настроили вот 
> тогда... :) ...было бы здорово.

наверное. 


-- 
Любимов Алексей
avl@l14.ru

Re: [sisyphus] chroot

[А.Л. Клютченя]

26 Сентябрь 2002 00:03, AHTOH написал:
> Если на файле стоит для меня ro я не могу в него записать.
> А под root могу. Под root я все могу. А чем он лучше? Тем что
> у него uid 0?
>
> rm -R * запустить в корне случайно и... потому что root!

	Рут, рут... :-) Любой с uid=0 будет как рут :-)

-- 
ВсехБлаг!       А. Л. Клютченя
 mail:	asoneofus@kde.ru
 www:	http://www.asoneofus.nm.ru
 icq:	113679387

Re: [sisyphus] chroot

[AHTOH]

26 Сентябрь 2002 01:19, Алексей Любимов написал:

> > _Сегодня_ механизм должен быть и надежным и простым в
> > использовании, тогда только есть в нем какой-то смысл.
> > Как совместить эти не совместимые вещи не моя задача.
>
> а чья?

Твоя. Ты же философ, программист, админ и все такое. :)

> придется перетачивать тонну приложений, которые считают, что
> рут может все. в castle это сделали для ограниченного
> серверного набора приложений.

Н-да. Трудновато.

> > Я конечно сам не буду этим заниматься, потому что и времени
> > нет и смысла.
>
> вот все так и говорят.
>
> > А вот если бы это сразу поставили и настроили вот
> > тогда... :) ...было бы здорово.
>
> наверное.

В общем. Так ничего и не измениться еще минимум лет 20.

-- 
Антон, SET RI

Re: [sisyphus] chroot

[А.Л. Клютченя]

26 Сентябрь 2002 22:10, AHTOH написал:
> > придется перетачивать тонну приложений, которые считают, что
> > рут может все. в castle это сделали для ограниченного
> > серверного набора приложений.

	Бесправный рут или его отсутствие - это тоже палка о двух 
концах...

-- 
ВсехБлаг!       А. Л. Клютченя
 mail:	asoneofus@kde.ru
 www:	http://www.asoneofus.nm.ru
 icq:	113679387

Re: [sisyphus] chroot

[Alexey V. Lubimov]

On Fri, 27 Sep 2002 08:46:48 +0400
"А.Л. Клютченя" <asoneofus@nm.ru> wrote:

> 26 Сентябрь 2002 22:10, AHTOH написал:
> > > придется перетачивать тонну приложений, которые считают, что
> > > рут может все. в castle это сделали для ограниченного
> > > серверного набора приложений.
> 
> 	Бесправный рут или его отсутствие - это тоже палка о двух 
> концах...

Контролируемый рут, а не бесправный.
RSBAC - совершенно другая система безопасности. 
Ее надо сначала изучить, понять основу, на которой она держится и только
тогда строить что либо с ее использованием.
Про бесконтрольность и всесилие рута в ситеме придется забыть
сразу и навсегда.

-- 
С уважением, Алексей Любимов avl@cad.ru

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

коль пошла речь о безопасности, то продолжим немножко:
сунулся я посмотреть на мастеровом сервере сколько и какие процессы у 
нас работают от рута:
(маленький коментарий: сервер предназначен для хождения в инет где-то 
около 10-и
пользователей, соответственно для этих пользователей на этом сервере
организованы почтовые ящики, прозрачный прокси, стоит апач для
нужд временно что-то в инет выложить, стоит самба для апача,
дистрибутив - мастер2, apt настроен на фтп альтлинукса -
i586 classic)
ну собственно вот:

[/home/dimka]$ ps axu|grep ^root
root         1  0.0  0.1  1268  484 ?        S    Sep22   0:04 init [3]
root         2  0.0  0.0     0    0 ?        SW   Sep22   0:00 [keventd]
root         3  0.0  0.0     0    0 ?        SWN  Sep22   0:04 
[ksoftirqd_CPU0]
root         4  0.0  0.0     0    0 ?        SW   Sep22   0:05 [kswapd]
root         5  0.0  0.0     0    0 ?        SW   Sep22   0:00 [bdflush]
root         6  0.0  0.0     0    0 ?        SW   Sep22   0:01 [kupdated]
root         7  0.0  0.0     0    0 ?        SW<  Sep22   0:00 [mdrecoveryd]
root       152  0.0  0.0     0    0 ?        SW   Sep22   0:00 [kjournald]
root       779  0.0  0.2  1572  708 ?        S    Sep22   0:59 
/sbin/syslog-ng
root       832  0.0  0.2  1480  644 ?        S    Sep22   0:00 crond
root       849  0.0  0.3  2076  892 ?        S    Sep22   0:07 
/usr/sbin/xinetd
root       866  0.0  0.4  2504 1260 ?        S    Sep22   0:06 
/usr/sbin/sshd
root      1309  0.0  0.4  3328 1168 ?        S    Sep22   0:04 
/usr/lib/postfix/
root      1346  0.0  0.4  3756 1108 ?        S    Sep22   0:00 squid -D
root      1366  0.0  0.7  4640 1956 ?        S    Sep22   0:00 smbd -D
root      1373  0.0  0.6  3592 1708 ?        S    Sep22   0:02 nmbd -D
root      1393  0.0  0.1  1232  416 tty1     S    Sep22   0:00 
/sbin/mingetty tt
root      1394  0.0  0.1  1232  416 tty2     S    Sep22   0:00 
/sbin/mingetty tt
root      1395  0.0  0.1  1232  416 tty3     S    Sep22   0:00 
/sbin/mingetty tt
root      1882  0.0  0.5  4212 1504 ?        S    Sep22   0:00 httpd 
-DHAVE_HTTP
root     22847  0.0  1.0  5128 2672 ?        S    15:18   0:00 smbd -D
root     22865  0.0  0.9  5116 2416 ?        S    15:22   0:00 smbd -D
root     23631  0.0  0.6  5840 1776 ?        S    18:07   0:00 
/usr/sbin/sshd

поехали:
1. первые семь пунктов - пропускаем - хез
2. 779 - логи - я не представляю как он работает, но может его можно 
было бы от какого юзера пускать ? - тоже пропускаем
3. 832 - планировщик, тут конечно в лоб - он должен от рута работать, 
хотя можно придумать безрутовую реализацию, ладно - тоже пропускаем
4. 849 - суперсервер
5. 1309 - мыло - тут непонятно - нафига ему рут ? и тем более чрут?
6. 1346 - прокся - вот уж кого не ожидал в этом списке увидеть!
7.  1366, 22847, 22865, 1373 - самба: тоже спрашивается нафига ей рут? - 
своя система авторизации (smbpasswd), может её от nobody пускать ?
    я не очень с ней разбирался но что-то мне подсказывает, что уж 
она-то должна иметь возможность от рута не работать....
8. 1393 1394 1395 - совсем непонятно зачем им рут ? если все равно на 
входе авторизацию всегда проводит - ну ладно - тут пропускаем
9. 1882 - апач - опять? кто тут рассказывал про чрут ? идите сюда!
10. 23631 - ssh - тоже по здравому размышлению рут ему не нужен

итак, самые "часто атакуемые сервера" - апач, постфикс, самба, ссш 
работают под рутом,
таким образом вопрос "а нафига им чрут?" очень актуален,
и еще более актуален вопрос вывода этих сервисов из под рута.

ладно - сквид - пускается из под рута, потом форки его уже от имени 
пользователя squid работают,
а почему его нельзя от этого пользователя и пускать ?
самба....

а постфикс сидит под чрутом ? зачем ?

Re: [sisyphus] chroot

[Dmitry V. Levin]

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

On Sun, Sep 29, 2002 at 06:46:29PM +0400, Dmitry E. Oboukhov wrote:
> коль пошла речь о безопасности, то продолжим немножко:
> сунулся я посмотреть на мастеровом сервере сколько и какие процессы у 
> нас работают от рута:
> (маленький коментарий: сервер предназначен для хождения в инет где-то 
> около 10-и
> пользователей, соответственно для этих пользователей на этом сервере
> организованы почтовые ящики, прозрачный прокси, стоит апач для
> нужд временно что-то в инет выложить, стоит самба для апача,
> дистрибутив - мастер2, apt настроен на фтп альтлинукса -
> i586 classic)
> ну собственно вот:
> 
> [/home/dimka]$ ps axu|grep ^root

Если вы хотите услышать от меня комментарий, то пришлите, пожалуйста,
вывод команды

$ ps afxuww |egrep "^(`awk -F: '{if ($3<500) print $1}' </etc/passwd |xargs echo |tr ' ' '|'`)[[:space:]]*"


--
ldv

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

Re: [sisyphus] chroot

["Алексей Любимов"]

> итак, самые "часто атакуемые сервера" - апач, постфикс, самба, ссш 
> работают под рутом,

"не верь глазам своим". 

> таким образом вопрос "а нафига им чрут?" очень актуален,

неактуален

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

> 
> ладно - сквид - пускается из под рута, потом форки его уже от имени 
> пользователя squid работают,
> а почему его нельзя от этого пользователя и пускать ?

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



> самба....

и самба.

> 
> а постфикс сидит под чрутом ? зачем ?

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

-- 
Любимов Алексей
avl@l14.ru

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

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

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

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

>
>
>Если вы хотите услышать от меня комментарий, то пришлите, пожалуйста,
>вывод команды
>
>$ ps afxuww |egrep "^(`awk -F: '{if ($3<500) print $1}' </etc/passwd |xargs echo |tr ' ' '|'`)[[:space:]]*"
>
>
>--
>ldv
>  
>

вывод достаточно большой получился:
[/home/dimka] $ ps afxuww |egrep "^(`awk -F: '{if ($3<500) print $1}' 
</etc/passwd |xargs echo |tr ' ' '|'`)[[:space:]]*"
root         6  0.0  0.0     0    0 ?        SW   Sep22   0:01 [kupdated]
root         5  0.0  0.0     0    0 ?        SW   Sep22   0:00 [bdflush]
root         4  0.0  0.0     0    0 ?        SW   Sep22   0:06 [kswapd]
root         3  0.0  0.0     0    0 ?        SWN  Sep22   0:06 
[ksoftirqd_CPU0]
root         1  0.0  0.1  1268  484 ?        S    Sep22   0:04 init [3]
root         2  0.0  0.0     0    0 ?        SW   Sep22   0:00 [keventd]
root         7  0.0  0.0     0    0 ?        SW<  Sep22   0:00 [mdrecoveryd]
root       152  0.0  0.0     0    0 ?        SW   Sep22   0:00 [kjournald]
root       779  0.0  0.2  1572  708 ?        S    Sep22   1:09 
/sbin/syslog-ng
klogd      796  0.0  0.4  1948 1152 ?        S    Sep22   0:04 
/sbin/klogd -c 1 -2 -u klogd -j /var/lib/klogd
atdaemon   815  0.0  0.2  1300  532 ?        S    Sep22   0:00 /usr/sbin/atd
root       832  0.0  0.2  1480  644 ?        S    Sep22   0:00 crond
root       849  0.0  0.3  2076  892 ?        S    Sep22   0:10 
/usr/sbin/xinetd -reuse -remlock
root       866  0.0  0.4  2504 1260 ?        S    Sep22   0:07 
/usr/sbin/sshd
root      3414  0.0  0.6  5840 1776 ?        S    12:19   0:00  \_ 
/usr/sbin/sshd
root      1309  0.0  0.4  3328 1168 ?        S    Sep22   0:05 
/usr/lib/postfix/master
postfix   1324  0.0  0.5  3492 1308 ?        S    Sep22   0:36  \_ qmgr 
-l -t fifo -u -c
postfix   3352  0.0  0.4  3508 1200 ?        S    12:10   0:00  \_ 
pickup -l -t fifo -u -c
postfix   3370  0.0  0.4  3520 1216 ?        S    12:15   0:00  \_ 
trivial-rewrite -n rewrite -t unix -u -c
postfix   3399  0.0  0.5  3752 1424 ?        S    12:18   0:00  \_ smtpd 
-n smtp -t inet -u -c -s 3
postfix   3400  0.0  0.5  3576 1288 ?        S    12:18   0:00  \_ 
cleanup -t unix -u -c
postfix   3401  0.0  0.5  4784 1436 ?        S    12:18   0:00  \_ local 
-t unix
postfix   3403  0.0  0.4  3512 1212 ?        S    12:18   0:00  \_ flush 
-t unix -u -c
root      1346  0.0  0.4  3756 1108 ?        S    Sep22   0:00 squid -D
squid     1348  0.0 18.5 49112 47584 ?       R    Sep22  12:21  \_ 
(squid) -D
squid     1365  0.0  0.1  1228  268 ?        S    Sep22   0:01      \_ 
(unlinkd)
root      1366  0.0  0.7  4640 1956 ?        S    Sep22   0:00 smbd -D
nobody    6540  0.9  1.1  5204 2892 ?        S    Sep27  57:01  \_ smbd -D
root     28447  0.0  1.0  5148 2672 ?        S    Sep30   0:07  \_ smbd -D
root      3116  0.0  0.9  5108 2388 ?        S    11:19   0:00  \_ smbd -D
root      3223  0.0  0.9  5112 2488 ?        S    11:42   0:00  \_ smbd -D
root      1373  0.0  0.6  3592 1708 ?        S    Sep22   0:03 nmbd -D
root      1393  0.0  0.1  1232  416 tty1     S    Sep22   0:00 
/sbin/mingetty tty1
root      1394  0.0  0.1  1232  416 tty2     S    Sep22   0:00 
/sbin/mingetty tty2
root      1395  0.0  0.1  1232  416 tty3     S    Sep22   0:00 
/sbin/mingetty tty3
root      1882  0.0  0.5  4212 1504 ?        S    Sep22   0:00 httpd 
-DHAVE_HTTPD -DHAVE_PROXY -DHAVE_ACCESS
-DHAVE_ACTIONS -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH -DHAVE_AUTH_ANON 
-DHAVE_AUTH_DB -DHAVE_AUTH_DIGEST -DHAVE_AUTOINDEX
-DHAVE_CERN_META -DHAVE_CGI -DHAVE_DEFINE -DHAVE_DIGEST -DHAVE_DIR 
-DHAVE_ENV -DHAVE_EXAMPLE -DHAVE_EXPIRES
-DHAVE_HEADERS -DHAVE_IMAP -DHAVE_INCLUDE -DHAVE_INFO -DHAVE_LOG_AGENT 
-DHAVE_LOG_CONFIG -DHAVE_LOG_REFERER -DHAVE_MIME
-DHAVE_MIME_MAGIC -DHAVE_MMAP_STATIC -DHAVE_NEGOTIATION -DHAVE_REWRITE 
-DHAVE_SETENVIF -DHAVE_SPELING -DHAVE_STATUS
-DHAVE_UNIQUE_ID -DHAVE_USERDIR -DHAVE_USERTRACK -DHAVE_VHOST_ALIAS
apache   17381  0.0  0.6  4432 1732 ?        S    Sep29   0:00  \_ httpd 
-DHAVE_HTTPD -DHAVE_PROXY -DHAVE_ACCESS
-DHAVE_ACTIONS -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH -DHAVE_AUTH_ANON 
-DHAVE_AUTH_DB -DHAVE_AUTH_DIGEST -DHAVE_AUTOINDEX
-DHAVE_CERN_META -DHAVE_CGI -DHAVE_DEFINE -DHAVE_DIGEST -DHAVE_DIR 
-DHAVE_ENV -DHAVE_EXAMPLE -DHAVE_EXPIRES
-DHAVE_HEADERS -DHAVE_IMAP -DHAVE_INCLUDE -DHAVE_INFO -DHAVE_LOG_AGENT 
-DHAVE_LOG_CONFIG -DHAVE_LOG_REFERER -DHAVE_MIME
-DHAVE_MIME_MAGIC -DHAVE_MMAP_STATIC -DHAVE_NEGOTIATION -DHAVE_REWRITE 
-DHAVE_SETENVIF -DHAVE_SPELING -DHAVE_STATUS
-DHAVE_UNIQUE_ID -DHAVE_USERDIR -DHAVE_USERTRACK -DHAVE_VHOST_ALIAS
apache   17382  0.0  0.6  4432 1764 ?        S    Sep29   0:00  \_ httpd 
-DHAVE_HTTPD -DHAVE_PROXY -DHAVE_ACCESS
-DHAVE_ACTIONS -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH -DHAVE_AUTH_ANON 
-DHAVE_AUTH_DB -DHAVE_AUTH_DIGEST -DHAVE_AUTOINDEX
-DHAVE_CERN_META -DHAVE_CGI -DHAVE_DEFINE -DHAVE_DIGEST -DHAVE_DIR 
-DHAVE_ENV -DHAVE_EXAMPLE -DHAVE_EXPIRES
-DHAVE_HEADERS -DHAVE_IMAP -DHAVE_INCLUDE -DHAVE_INFO -DHAVE_LOG_AGENT 
-DHAVE_LOG_CONFIG -DHAVE_LOG_REFERER -DHAVE_MIME
-DHAVE_MIME_MAGIC -DHAVE_MMAP_STATIC -DHAVE_NEGOTIATION -DHAVE_REWRITE 
-DHAVE_SETENVIF -DHAVE_SPELING -DHAVE_STATUS
-DHAVE_UNIQUE_ID -DHAVE_USERDIR -DHAVE_USERTRACK -DHAVE_VHOST_ALIAS
apache   17383  0.0  0.6  4440 1748 ?        S    Sep29   0:00  \_ httpd 
-DHAVE_HTTPD -DHAVE_PROXY -DHAVE_ACCESS
-DHAVE_ACTIONS -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH -DHAVE_AUTH_ANON 
-DHAVE_AUTH_DB -DHAVE_AUTH_DIGEST -DHAVE_AUTOINDEX
-DHAVE_CERN_META -DHAVE_CGI -DHAVE_DEFINE -DHAVE_DIGEST -DHAVE_DIR 
-DHAVE_ENV -DHAVE_EXAMPLE -DHAVE_EXPIRES
-DHAVE_HEADERS -DHAVE_IMAP -DHAVE_INCLUDE -DHAVE_INFO -DHAVE_LOG_AGENT 
-DHAVE_LOG_CONFIG -DHAVE_LOG_REFERER -DHAVE_MIME
-DHAVE_MIME_MAGIC -DHAVE_MMAP_STATIC -DHAVE_NEGOTIATION -DHAVE_REWRITE 
-DHAVE_SETENVIF -DHAVE_SPELING -DHAVE_STATUS
-DHAVE_UNIQUE_ID -DHAVE_USERDIR -DHAVE_USERTRACK -DHAVE_VHOST_ALIAS
apache   17384  0.0  0.6  4444 1764 ?        S    Sep29   0:00  \_ httpd 
-DHAVE_HTTPD -DHAVE_PROXY -DHAVE_ACCESS
-DHAVE_ACTIONS -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH -DHAVE_AUTH_ANON 
-DHAVE_AUTH_DB -DHAVE_AUTH_DIGEST -DHAVE_AUTOINDEX
-DHAVE_CERN_META -DHAVE_CGI -DHAVE_DEFINE -DHAVE_DIGEST -DHAVE_DIR 
-DHAVE_ENV -DHAVE_EXAMPLE -DHAVE_EXPIRES
-DHAVE_HEADERS -DHAVE_IMAP -DHAVE_INCLUDE -DHAVE_INFO -DHAVE_LOG_AGENT 
-DHAVE_LOG_CONFIG -DHAVE_LOG_REFERER -DHAVE_MIME
-DHAVE_MIME_MAGIC -DHAVE_MMAP_STATIC -DHAVE_NEGOTIATION -DHAVE_REWRITE 
-DHAVE_SETENVIF -DHAVE_SPELING -DHAVE_STATUS
-DHAVE_UNIQUE_ID -DHAVE_USERDIR -DHAVE_USERTRACK -DHAVE_VHOST_ALIAS
apache   17444  0.0  0.6  4444 1760 ?        S    Sep29   0:00  \_ httpd 
-DHAVE_HTTPD -DHAVE_PROXY -DHAVE_ACCESS
-DHAVE_ACTIONS -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH -DHAVE_AUTH_ANON 
-DHAVE_AUTH_DB -DHAVE_AUTH_DIGEST -DHAVE_AUTOINDEX
-DHAVE_CERN_META -DHAVE_CGI -DHAVE_DEFINE -DHAVE_DIGEST -DHAVE_DIR 
-DHAVE_ENV -DHAVE_EXAMPLE -DHAVE_EXPIRES
-DHAVE_HEADERS -DHAVE_IMAP -DHAVE_INCLUDE -DHAVE_INFO -DHAVE_LOG_AGENT 
-DHAVE_LOG_CONFIG -DHAVE_LOG_REFERER -DHAVE_MIME
-DHAVE_MIME_MAGIC -DHAVE_MMAP_STATIC -DHAVE_NEGOTIATION -DHAVE_REWRITE 
-DHAVE_SETENVIF -DHAVE_SPELING -DHAVE_STATUS
-DHAVE_UNIQUE_ID -DHAVE_USERDIR -DHAVE_USERTRACK -DHAVE_VHOST_ALIAS
apache   17445  0.0  0.7  4456 1804 ?        S    Sep29   0:00  \_ httpd 
-DHAVE_HTTPD -DHAVE_PROXY -DHAVE_ACCESS
-DHAVE_ACTIONS -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH -DHAVE_AUTH_ANON 
-DHAVE_AUTH_DB -DHAVE_AUTH_DIGEST -DHAVE_AUTOINDEX
-DHAVE_CERN_META -DHAVE_CGI -DHAVE_DEFINE -DHAVE_DIGEST -DHAVE_DIR 
-DHAVE_ENV -DHAVE_EXAMPLE -DHAVE_EXPIRES
-DHAVE_HEADERS -DHAVE_IMAP -DHAVE_INCLUDE -DHAVE_INFO -DHAVE_LOG_AGENT 
-DHAVE_LOG_CONFIG -DHAVE_LOG_REFERER -DHAVE_MIME
-DHAVE_MIME_MAGIC -DHAVE_MMAP_STATIC -DHAVE_NEGOTIATION -DHAVE_REWRITE 
-DHAVE_SETENVIF -DHAVE_SPELING -DHAVE_STATUS
-DHAVE_UNIQUE_ID -DHAVE_USERDIR -DHAVE_USERTRACK -DHAVE_VHOST_ALIAS
apache   17895  0.0  0.6  4432 1736 ?        S    Sep29   0:00  \_ httpd 
-DHAVE_HTTPD -DHAVE_PROXY -DHAVE_ACCESS
-DHAVE_ACTIONS -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH -DHAVE_AUTH_ANON 
-DHAVE_AUTH_DB -DHAVE_AUTH_DIGEST -DHAVE_AUTOINDEX
-DHAVE_CERN_META -DHAVE_CGI -DHAVE_DEFINE -DHAVE_DIGEST -DHAVE_DIR 
-DHAVE_ENV -DHAVE_EXAMPLE -DHAVE_EXPIRES
-DHAVE_HEADERS -DHAVE_IMAP -DHAVE_INCLUDE -DHAVE_INFO -DHAVE_LOG_AGENT 
-DHAVE_LOG_CONFIG -DHAVE_LOG_REFERER -DHAVE_MIME
-DHAVE_MIME_MAGIC -DHAVE_MMAP_STATIC -DHAVE_NEGOTIATION -DHAVE_REWRITE 
-DHAVE_SETENVIF -DHAVE_SPELING -DHAVE_STATUS
-DHAVE_UNIQUE_ID -DHAVE_USERDIR -DHAVE_USERTRACK -DHAVE_VHOST_ALIAS
apache   17896  0.0  0.6  4444 1776 ?        S    Sep29   0:00  \_ httpd 
-DHAVE_HTTPD -DHAVE_PROXY -DHAVE_ACCESS
-DHAVE_ACTIONS -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH -DHAVE_AUTH_ANON 
-DHAVE_AUTH_DB -DHAVE_AUTH_DIGEST -DHAVE_AUTOINDEX
-DHAVE_CERN_META -DHAVE_CGI -DHAVE_DEFINE -DHAVE_DIGEST -DHAVE_DIR 
-DHAVE_ENV -DHAVE_EXAMPLE -DHAVE_EXPIRES
-DHAVE_HEADERS -DHAVE_IMAP -DHAVE_INCLUDE -DHAVE_INFO -DHAVE_LOG_AGENT 
-DHAVE_LOG_CONFIG -DHAVE_LOG_REFERER -DHAVE_MIME
-DHAVE_MIME_MAGIC -DHAVE_MMAP_STATIC -DHAVE_NEGOTIATION -DHAVE_REWRITE 
-DHAVE_SETENVIF -DHAVE_SPELING -DHAVE_STATUS
-DHAVE_UNIQUE_ID -DHAVE_USERDIR -DHAVE_USERTRACK -DHAVE_VHOST_ALIAS
apache   17917  0.0  0.6  4444 1784 ?        S    Sep29   0:00  \_ httpd 
-DHAVE_HTTPD -DHAVE_PROXY -DHAVE_ACCESS
-DHAVE_ACTIONS -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH -DHAVE_AUTH_ANON 
-DHAVE_AUTH_DB -DHAVE_AUTH_DIGEST -DHAVE_AUTOINDEX
-DHAVE_CERN_META -DHAVE_CGI -DHAVE_DEFINE -DHAVE_DIGEST -DHAVE_DIR 
-DHAVE_ENV -DHAVE_EXAMPLE -DHAVE_EXPIRES
-DHAVE_HEADERS -DHAVE_IMAP -DHAVE_INCLUDE -DHAVE_INFO -DHAVE_LOG_AGENT 
-DHAVE_LOG_CONFIG -DHAVE_LOG_REFERER -DHAVE_MIME
-DHAVE_MIME_MAGIC -DHAVE_MMAP_STATIC -DHAVE_NEGOTIATION -DHAVE_REWRITE 
-DHAVE_SETENVIF -DHAVE_SPELING -DHAVE_STATUS
-DHAVE_UNIQUE_ID -DHAVE_USERDIR -DHAVE_USERTRACK -DHAVE_VHOST_ALIAS
apache   20655  0.0  0.6  4432 1732 ?        S    Sep29   0:00  \_ httpd 
-DHAVE_HTTPD -DHAVE_PROXY -DHAVE_ACCESS
-DHAVE_ACTIONS -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH -DHAVE_AUTH_ANON 
-DHAVE_AUTH_DB -DHAVE_AUTH_DIGEST -DHAVE_AUTOINDEX
-DHAVE_CERN_META -DHAVE_CGI -DHAVE_DEFINE -DHAVE_DIGEST -DHAVE_DIR 
-DHAVE_ENV -DHAVE_EXAMPLE -DHAVE_EXPIRES
-DHAVE_HEADERS -DHAVE_IMAP -DHAVE_INCLUDE -DHAVE_INFO -DHAVE_LOG_AGENT 
-DHAVE_LOG_CONFIG -DHAVE_LOG_REFERER -DHAVE_MIME
-DHAVE_MIME_MAGIC -DHAVE_MMAP_STATIC -DHAVE_NEGOTIATION -DHAVE_REWRITE 
-DHAVE_SETENVIF -DHAVE_SPELING -DHAVE_STATUS
-DHAVE_UNIQUE_ID -DHAVE_USERDIR -DHAVE_USERTRACK -DHAVE_VHOST_ALIAS

[sisyphus] Re: chroot

[Michael Shigorin]

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

On Tue, Oct 01, 2002 at 11:55:21AM +0400, Dmitry E. Oboukhov wrote:
> а если сделать так, что каждый, кто может почту получать
> должен быть прописан в какой-нибудь группе ?

открытие сокетов, etc -- все равно потребуют рута.  и чисто
технологически мне почему-то кажется, что fork-auth-схема сейчас
уже обкатана гораздо более, чем мозги администраторов, которым Вы
предлагаете подобные ...эээ... решения.

> создавать юзеров будет конечно гиморно, но можно будет скрипт
> написать, который будет у юзера каталоги с нужными правами
> создавать, или линки на нужные файлы в юзерском каталоге...

костыли.

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

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

Re: [sisyphus] Re: chroot

[Dmitry E. Oboukhov]

Michael Shigorin wrote:

>On Tue, Oct 01, 2002 at 11:55:21AM +0400, Dmitry E. Oboukhov wrote:
>  
>
>>а если сделать так, что каждый, кто может почту получать
>>должен быть прописан в какой-нибудь группе ?
>>    
>>
>
>открытие сокетов, etc -- все равно потребуют рута.  
>
а почему? разве нельзя опять группу завести на ето ?

>и чисто
>технологически мне почему-то кажется, что fork-auth-схема сейчас
>уже обкатана гораздо более, чем мозги администраторов, которым Вы
>предлагаете подобные ...эээ... решения.
>
может тут Вы и правы, только насколько я понимаю администраторы
ставят все сервера в двух вариантах:
1. Из RPM/DEB и дальше только правят конфиги. Для них все будет работать
так, как оно задумано в дистрибутиве/репозитарии

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

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

Re: [sisyphus] chroot

[Dmitry V. Levin]

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

On Tue, Oct 01, 2002 at 12:01:42PM +0400, Dmitry E. Oboukhov wrote:
> >Если вы хотите услышать от меня комментарий, то пришлите, пожалуйста,
> >вывод команды
> >
> >$ ps afxuww |egrep "^(`awk -F: '{if ($3<500) print $1}' </etc/passwd 
> >|xargs echo |tr ' ' '|'`)[[:space:]]*"
> 
> вывод достаточно большой получился:
> [/home/dimka] $ ps afxuww |egrep "^(`awk -F: '{if ($3<500) print $1}' 
> </etc/passwd |xargs echo |tr ' ' '|'`)[[:space:]]*"
> root         6  0.0  0.0     0    0 ?        SW   Sep22   0:01 [kupdated]
> root         5  0.0  0.0     0    0 ?        SW   Sep22   0:00 [bdflush]
> root         4  0.0  0.0     0    0 ?        SW   Sep22   0:06 [kswapd]
> root         3  0.0  0.0     0    0 ?        SWN  Sep22   0:06 [ksoftirqd_CPU0]
> root         1  0.0  0.1  1268  484 ?        S    Sep22   0:04 init [3]
> root         2  0.0  0.0     0    0 ?        SW   Sep22   0:00 [keventd]
> root         7  0.0  0.0     0    0 ?        SW<  Sep22   0:00 [mdrecoveryd]
> root       152  0.0  0.0     0    0 ?        SW   Sep22   0:00 [kjournald]

Это kernel threads + init.

> root       779  0.0  0.2  1572  708 ?        S    Sep22   1:09 /sbin/syslog-ng

Не знаю, почему люди ставят syslog-ng.
syslogd работает под псевдопользователем (и в readonly
chroot jail, если сконфигурирован).

> klogd      796  0.0  0.4  1948 1152 ?        S    Sep22   0:04 /sbin/klogd -c 1 -2 -u klogd -j /var/lib/klogd

Работает под псевдопользователем в readonly chroot jail.

> atdaemon   815  0.0  0.2  1300  532 ?        S    Sep22   0:00 /usr/sbin/atd

Работает с эффективными правами псевдопользователя (все равно нужен
как минимум CAP_SETUID в некоторые моменты работы).

> root       832  0.0  0.2  1480  644 ?        S    Sep22   0:00 crond

Нужен как минимум CAP_SETUID.

> root       849  0.0  0.3  2076  892 ?        S    Sep22   0:10 /usr/sbin/xinetd -reuse -remlock

Нужен как минимум CAP_SETUID+CAP_NET_BIND_SERVICE.

> root       866  0.0  0.4  2504 1260 ?        S    Sep22   0:07 /usr/sbin/sshd
> root      3414  0.0  0.6  5840 1776 ?        S    12:19   0:00  \_/usr/sbin/sshd

Нужен root для авторизации пользователей.

> root      1309  0.0  0.4  3328 1168 ?        S    Sep22   0:05 /usr/lib/postfix/master

Это управляющий сервер postfix'а; вся основная работа ведется в
компонентах.

> postfix   1324  0.0  0.5  3492 1308 ?        S    Sep22   0:36  \_ qmgr -l -t fifo -u -c
> postfix   3352  0.0  0.4  3508 1200 ?        S    12:10   0:00  \_ pickup -l -t fifo -u -c
> postfix   3370  0.0  0.4  3520 1216 ?        S    12:15   0:00  \_ trivial-rewrite -n rewrite -t unix -u -c
> postfix   3399  0.0  0.5  3752 1424 ?        S    12:18   0:00  \_ smtpd -n smtp -t inet -u -c -s 3
> postfix   3400  0.0  0.5  3576 1288 ?        S    12:18   0:00  \_ cleanup -t unix -u -c
> postfix   3401  0.0  0.5  4784 1436 ?        S    12:18   0:00  \_ local -t unix
> postfix   3403  0.0  0.4  3512 1212 ?        S    12:18   0:00  \_ flush -t unix -u -c

Компоненты postfix'а; все работают с правами псевдопользователя postfix,
большинство - в специальном chroot jail.

> root      1346  0.0  0.4  3756 1108 ?        S    Sep22   0:00 squid -D
> squid     1348  0.0 18.5 49112 47584 ?       R    Sep22  12:21  \_ (squid) -D
> squid     1365  0.0  0.1  1228  268 ?        S    Sep22   0:01      \_ (unlinkd)

Управляющий сервер - root;
все остальные - псевдопользователи.
В принципе, и управляющий сервер можно сконфигурировать работать с правами
псевдопользователя в chroot jail; при этом будет потеряна часть
функциональности.
В принципе, тут есть над чем поработать.

> root      1366  0.0  0.7  4640 1956 ?        S    Sep22   0:00 smbd -D
> nobody    6540  0.9  1.1  5204 2892 ?        S    Sep27  57:01  \_ smbd -D
> root     28447  0.0  1.0  5148 2672 ?        S    Sep30   0:07  \_ smbd -D
> root      3116  0.0  0.9  5108 2388 ?        S    11:19   0:00  \_ smbd -D
> root      3223  0.0  0.9  5112 2488 ?        S    11:42   0:00  \_ smbd -D
> root      1373  0.0  0.6  3592 1708 ?        S    Sep22   0:03 nmbd -D

Самба авторизует пользователей.

> root      1393  0.0  0.1  1232  416 tty1     S    Sep22   0:00 /sbin/mingetty tty1
> root      1394  0.0  0.1  1232  416 tty2     S    Sep22   0:00 /sbin/mingetty tty2
> root      1395  0.0  0.1  1232  416 tty3     S    Sep22   0:00 /sbin/mingetty tty3

Нужен CAP_SYS_TTY_CONFIG для vhangup() на терминал.

> root      1882  0.0  0.5  4212 1504 ?        S    Sep22   0:00 httpd 
> apache   17381  0.0  0.6  4432 1732 ?        S    Sep29   0:00  \_ httpd 
> apache   17382  0.0  0.6  4432 1764 ?        S    Sep29   0:00  \_ httpd 
> apache   17383  0.0  0.6  4440 1748 ?        S    Sep29   0:00  \_ httpd 
> apache   17384  0.0  0.6  4444 1764 ?        S    Sep29   0:00  \_ httpd 
> apache   17444  0.0  0.6  4444 1760 ?        S    Sep29   0:00  \_ httpd 
> apache   17445  0.0  0.7  4456 1804 ?        S    Sep29   0:00  \_ httpd 
> apache   17895  0.0  0.6  4432 1736 ?        S    Sep29   0:00  \_ httpd 
> apache   17896  0.0  0.6  4444 1776 ?        S    Sep29   0:00  \_ httpd 
> apache   17917  0.0  0.6  4444 1784 ?        S    Sep29   0:00  \_ httpd 
> apache   20655  0.0  0.6  4432 1732 ?        S    Sep29   0:00  \_ httpd 

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


--
ldv

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

[sisyphus] Re: chroot

[Michael Shigorin]

On Tue, Oct 01, 2002 at 12:10:04PM +0400, Dmitry E. Oboukhov wrote:
> >открытие сокетов, etc -- все равно потребуют рута.  
> а почему? разве нельзя опять группу завести на ето ?

ahem.  RTFS основы UNIX и, в частности,
/usr/src/linux/net/core/sock.c, если не ошибаюсь?

> может тут Вы и правы, только насколько я понимаю администраторы
> ставят все сервера в двух вариантах:
> 1. Из RPM/DEB и дальше только правят конфиги. Для них все будет
> работать так, как оно задумано в дистрибутиве/репозитарии

Ну.  Это не повод устраивать из него костыльный ряд.

> 2. Те которые будут править права - но им и репозитарий не нужен
> - они все равно собирать ето все будут...

В 99% случаев лично мне до них просто нет дела -- каждый сам ищет
себе проблемы.

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

Re: [sisyphus] Re: chroot

[Gerasimov Dmitry]

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

On Tue, Oct 01, 2002 at 12:10:04PM +0400, Dmitry E. Oboukhov wrote:
> Michael Shigorin wrote:
> 
> >On Tue, Oct 01, 2002 at 11:55:21AM +0400, Dmitry E. Oboukhov wrote:
> > 
> >
> >>а если сделать так, что каждый, кто может почту получать
> >>должен быть прописан в какой-нибудь группе ?
> >>   
> >>
> >
> >открытие сокетов, etc -- все равно потребуют рута.  
> >
> а почему? разве нельзя опять группу завести на ето ?
> 
> >и чисто
> >технологически мне почему-то кажется, что fork-auth-схема сейчас
> >уже обкатана гораздо более, чем мозги администраторов, которым Вы
> >предлагаете подобные ...эээ... решения.
> >
> может тут Вы и правы, только насколько я понимаю администраторы
> ставят все сервера в двух вариантах:
> 1. Из RPM/DEB и дальше только правят конфиги. Для них все будет работать
> так, как оно задумано в дистрибутиве/репозитарии
> 
> 2. Те которые будут править права - но им и репозитарий не нужен
> - они все равно собирать ето все будут...
> 
есть еще третьи. те кто ставят минимум пакетов, а после _ВСЕ_ собирают из 
исходников, руками накладывая все необходимые пачти. и т.д. после всего 
убивая из системы rpm и перемещаю компиляторы в недоступное место (дискету)
по этому поводу есть изумительная книга :
OpenNA: Securing & Optimizing Linux : The Hacking Solution.(www.openna.com)

    ----------------------------
	Dmitry S. Gerasimov
        ICQ: 26277841
	JID: q2digger@mail.ru
    ----------------------------

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

Re: [sisyphus] Re: chroot

[Gerasimov Dmitry]

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

On Tue, Oct 01, 2002 at 12:50:50PM +0400, Anton V. Boyarshinov wrote:
> On Tue, 1 Oct 2002 12:37:18 +0400
> Gerasimov Dmitry <matrix@podlipki.ru> wrote:
> 
> > есть еще третьи. те кто ставят минимум пакетов, а после _ВСЕ_
> > собирают из исходников, руками накладывая все необходимые
> > пачти. и т.д. после всего убивая из системы rpm и перемещаю
> > компиляторы в недоступное место (дискету) по этому поводу есть
> > изумительная книга :
> 
> Это очень странные люди и они очень мало ценят своё время
> (впрочем, скорее всего это просто такое хобби). 
> 
нет. это _хорошо_ выполненная работа.

> Антон
> -- 
> mailto:boyarsh@mail.ru
> mailto:boyarsh@ru.echo.fr
>  12:48pm  up 39 days,  5:02,  5 users,  load average: 0.00, 0.00,
> 0.00
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@altlinux.ru
> http://altlinux.ru/mailman/listinfo/sisyphus
    ----------------------------
	Dmitry S. Gerasimov
        ICQ: 26277841
	JID: q2digger@mail.ru
    ----------------------------

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

Re: [sisyphus] Re: chroot

[Anton V. Boyarshinov]

On Tue, 1 Oct 2002 12:37:18 +0400
Gerasimov Dmitry <matrix@podlipki.ru> wrote:

> есть еще третьи. те кто ставят минимум пакетов, а после _ВСЕ_
> собирают из исходников, руками накладывая все необходимые
> пачти. и т.д. после всего убивая из системы rpm и перемещаю
> компиляторы в недоступное место (дискету) по этому поводу есть
> изумительная книга :

Это очень странные люди и они очень мало ценят своё время
(впрочем, скорее всего это просто такое хобби). 

Антон
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 12:48pm  up 39 days,  5:02,  5 users,  load average: 0.00, 0.00,
0.00

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

>
>
>>root       779  0.0  0.2  1572  708 ?        S    Sep22   1:09 /sbin/syslog-ng
>>    
>>
>
>Не знаю, почему люди ставят syslog-ng.
>syslogd работает под псевдопользователем (и в readonly
>chroot jail, если сконфигурирован).
>
стоит с момента инсталла мастера - поставил, дальше не задумывался
что там стоит? сейчас гляну на syslogd, если он лучше может сделать,
чтобы он ставился в дистрибутиве по умолчанию, а syslog-ng - только
дополнительно?

>>klogd      796  0.0  0.4  1948 1152 ?        S    Sep22   0:04 /sbin/klogd -c 1 -2 -u klogd -j /var/lib/klogd
>>    
>>
>
>Работает под псевдопользователем в readonly chroot jail.
>
прекрасно

>>atdaemon   815  0.0  0.2  1300  532 ?        S    Sep22   0:00 /usr/sbin/atd
>>    
>>
>
>Работает с эффективными правами псевдопользователя (все равно нужен
>как минимум CAP_SETUID в некоторые моменты работы).
>
то, что ему нужен setuid в некоторые моменты это понятно,
но вот почему бы работу крона так же не организовать, ведь
по сути at и cron - одно и тоже ;)

>>root       832  0.0  0.2  1480  644 ?        S    Sep22   0:00 crond
>>    
>>
>
>Нужен как минимум CAP_SETUID.
>
см. выше

>>root       849  0.0  0.3  2076  892 ?        S    Sep22   0:10 /usr/sbin/xinetd -reuse -remlock
>>    
>>
>
>Нужен как минимум CAP_SETUID+CAP_NET_BIND_SERVICE.
>  
>
тут насколько я понимаю от рута крайне тяжело избавиться -
будет либо резкое снижение функциональности, либо обширное
расширение прав какой-то группы...

>>root       866  0.0  0.4  2504 1260 ?        S    Sep22   0:07 /usr/sbin/sshd
>>root      3414  0.0  0.6  5840 1776 ?        S    12:19   0:00  \_/usr/sbin/sshd
>>    
>>
>
>Нужен root для авторизации пользователей.
>
проясните пожалуйста

допустим я имею логин и пассворд пользователя (мб рута)

char *login="vasya";
char *passwd="pupkin";
разве этого недостаточно чтобы сделать программный su?

>>root      1309  0.0  0.4  3328 1168 ?        S    Sep22   0:05 /usr/lib/postfix/master
>>    
>>
>
>Это управляющий сервер postfix'а; вся основная работа ведется в
>компонентах.
>
>  
>
>>postfix   1324  0.0  0.5  3492 1308 ?        S    Sep22   0:36  \_ qmgr -l -t fifo -u -c
>>postfix   3352  0.0  0.4  3508 1200 ?        S    12:10   0:00  \_ pickup -l -t fifo -u -c
>>postfix   3370  0.0  0.4  3520 1216 ?        S    12:15   0:00  \_ trivial-rewrite -n rewrite -t unix -u -c
>>postfix   3399  0.0  0.5  3752 1424 ?        S    12:18   0:00  \_ smtpd -n smtp -t inet -u -c -s 3
>>postfix   3400  0.0  0.5  3576 1288 ?        S    12:18   0:00  \_ cleanup -t unix -u -c
>>postfix   3401  0.0  0.5  4784 1436 ?        S    12:18   0:00  \_ local -t unix
>>postfix   3403  0.0  0.4  3512 1212 ?        S    12:18   0:00  \_ flush -t unix -u -c
>>    
>>
>
>Компоненты postfix'а; все работают с правами псевдопользователя postfix,
>большинство - в специальном chroot jail.
>
>  
>
>>root      1346  0.0  0.4  3756 1108 ?        S    Sep22   0:00 squid -D
>>squid     1348  0.0 18.5 49112 47584 ?       R    Sep22  12:21  \_ (squid) -D
>>squid     1365  0.0  0.1  1228  268 ?        S    Sep22   0:01      \_ (unlinkd)
>>    
>>
>
>Управляющий сервер - root;
>все остальные - псевдопользователи.
>В принципе, и управляющий сервер можно сконфигурировать работать с правами
>псевдопользователя в chroot jail; при этом будет потеряна часть
>функциональности.
>В принципе, тут есть над чем поработать.
>
что в функциональности прокси может быть потеряно ?

>>root      1366  0.0  0.7  4640 1956 ?        S    Sep22   0:00 smbd -D
>>nobody    6540  0.9  1.1  5204 2892 ?        S    Sep27  57:01  \_ smbd -D
>>root     28447  0.0  1.0  5148 2672 ?        S    Sep30   0:07  \_ smbd -D
>>root      3116  0.0  0.9  5108 2388 ?        S    11:19   0:00  \_ smbd -D
>>root      3223  0.0  0.9  5112 2488 ?        S    11:42   0:00  \_ smbd -D
>>root      1373  0.0  0.6  3592 1708 ?        S    Sep22   0:03 nmbd -D
>>    
>>
>
>Самба авторизует пользователей.
>
см выше вопрос про ССШ

>
>  
>
>>root      1393  0.0  0.1  1232  416 tty1     S    Sep22   0:00 /sbin/mingetty tty1
>>root      1394  0.0  0.1  1232  416 tty2     S    Sep22   0:00 /sbin/mingetty tty2
>>root      1395  0.0  0.1  1232  416 tty3     S    Sep22   0:00 /sbin/mingetty tty3
>>    
>>
>
>Нужен CAP_SYS_TTY_CONFIG для vhangup() на терминал.
>
права доступа ?

>
>  
>
>>root      1882  0.0  0.5  4212 1504 ?        S    Sep22   0:00 httpd 
>>apache   17381  0.0  0.6  4432 1732 ?        S    Sep29   0:00  \_ httpd 
>>apache   17382  0.0  0.6  4432 1764 ?        S    Sep29   0:00  \_ httpd 
>>apache   17383  0.0  0.6  4440 1748 ?        S    Sep29   0:00  \_ httpd 
>>apache   17384  0.0  0.6  4444 1764 ?        S    Sep29   0:00  \_ httpd 
>>apache   17444  0.0  0.6  4444 1760 ?        S    Sep29   0:00  \_ httpd 
>>apache   17445  0.0  0.7  4456 1804 ?        S    Sep29   0:00  \_ httpd 
>>apache   17895  0.0  0.6  4432 1736 ?        S    Sep29   0:00  \_ httpd 
>>apache   17896  0.0  0.6  4444 1776 ?        S    Sep29   0:00  \_ httpd 
>>apache   17917  0.0  0.6  4444 1784 ?        S    Sep29   0:00  \_ httpd 
>>apache   20655  0.0  0.6  4432 1732 ?        S    Sep29   0:00  \_ httpd 
>>    
>>
>
>Управляющий сервер - root;
>все остальные - псевдопользователи.
>В принципе, и управляющий сервер можно сконфигурировать работать с правами
>псевдопользователя; при этом будет потеряна часть функциональности.
>
>  
>
опять же какая часть ?
сервер он вроде "сам по себе сервер" зачем ему рут ?
только для того, чтобы сокеты открывать ?

Re: [sisyphus] Re: chroot

[Gerasimov Dmitry]

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

> > нет. это _хорошо_ выполненная работа.
> 
> Это _плохо_ выполненная работа, если копнуть чуть глубже.  Потому
> что если такому оболтусу завтра упадет кирпич на голову,
> послезавтра найдут дырку, а к концу недели сервер ляжет -- вот
> тут-то все и вылезет.
> 
> Прошу Вас -- не начинайте гам, потому как позиция заведомо
> проигрышная.  Домашнее задание -- обдумать фразу "you can't
> always patch fast enough" (особенно в свете того, что разбираться
> досконально "во всем" и применять это аж для двух, ну десяти
> машин -- бред или маргинальный случай), а также поразмыслить над
> тем, что наиболее эффективный метод использования такого вот
> патчера -- это приковывание к серверу в режиме 24x7 и капельница
> с кофеином.
Михаил, как можно обсуждать то, что даже не видел.
этот тред я переношу в procmail - deny. Тут здоровых аргументов
нету уже дня три.
> 
> Автоматика и knowledge/effort reuse -- вот это правильно.
> 
> PS: торжественно выгоняю себя и всю эту тему в talk-room.
> 
> -- 
>  ---- WBR, Michael Shigorin <mike@altlinux.ru>
>   ------ Linux.Kiev http://www.linux.kiev.ua/


    ----------------------------
	Dmitry S. Gerasimov
        ICQ: 26277841
	JID: q2digger@mail.ru
    ----------------------------

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

[sisyphus] Re: chroot

[Michael Shigorin]

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

On Tue, Oct 01, 2002 at 12:50:27PM +0400, Gerasimov Dmitry wrote:
> > > есть еще третьи. те кто ставят минимум пакетов, а после _ВСЕ_
> > > собирают из исходников, руками накладывая все необходимые
> > > пачти. и т.д. после всего убивая из системы rpm и перемещаю
> > > компиляторы в недоступное место (дискету) по этому поводу есть
> > > изумительная книга :

Знаете, я читал первое издание этого руководства.  Оно местами
напоминает чуточку более ранние высказывания route9 (iirc) на
тему "сделайте chmod -R 700 / и работайте только рутом"
(всерьез!!! это "засекьюривание"!!!), ну и вообще как бы местами
наивно.

> > Это очень странные люди и они очень мало ценят своё время
> > (впрочем, скорее всего это просто такое хобби). 

Мягкая характеристика.

> нет. это _хорошо_ выполненная работа.

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

Прошу Вас -- не начинайте гам, потому как позиция заведомо
проигрышная.  Домашнее задание -- обдумать фразу "you can't
always patch fast enough" (особенно в свете того, что разбираться
досконально "во всем" и применять это аж для двух, ну десяти
машин -- бред или маргинальный случай), а также поразмыслить над
тем, что наиболее эффективный метод использования такого вот
патчера -- это приковывание к серверу в режиме 24x7 и капельница
с кофеином.

Автоматика и knowledge/effort reuse -- вот это правильно.

PS: торжественно выгоняю себя и всю эту тему в talk-room.

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

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

Re: [sisyphus] Re: chroot

[Anton V. Boyarshinov]

On Tue, 1 Oct 2002 12:50:27 +0400
Gerasimov Dmitry <matrix@podlipki.ru> wrote:
> > 
> > > есть еще третьи. те кто ставят минимум пакетов, а после
> > > _ВСЕ_ собирают из исходников, руками накладывая все
> > > необходимые пачти. и т.д. после всего убивая из системы rpm
> > > и перемещаю компиляторы в недоступное место (дискету) по
> > > этому поводу есть изумительная книга :
> > 
> > Это очень странные люди и они очень мало ценят своё время
> > (впрочем, скорее всего это просто такое хобби). 
> > 
> нет. это _хорошо_ выполненная работа.
Это плохо выполненная работа. Хорошо выполненная работа это когда
все пакеты, которые действительно нуждаются в пересборке
пересобираются и размещаются в локальном репозитории. В противном
случае поддержка нескольких (десятков) серверов превращается в
рай для мазохиста и рано или поздно одна из программ на одном из
серверов не будет обновлена. Пересборка же ВСЕГО может быть
объяснена только религиозными причинами.

Антон
PS с этой темой завязываю, бо оффтопик
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
  1:08pm  up 39 days,  5:22,  5 users,  load average: 0.02, 0.09,
0.04

Re: [sisyphus] chroot

[Dmitry V. Levin]

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

On Tue, Oct 01, 2002 at 12:57:47PM +0400, Dmitry E. Oboukhov wrote:
> стоит с момента инсталла мастера - поставил, дальше не задумывался
> что там стоит? сейчас гляну на syslogd, если он лучше может сделать,
> чтобы он ставился в дистрибутиве по умолчанию, а syslog-ng - только
> дополнительно?

Думаю, так и будет.
Более того, мне казалось, что так и было. :)

> то, что ему нужен setuid в некоторые моменты это понятно,
> но вот почему бы работу крона так же не организовать, ведь
> по сути at и cron - одно и тоже ;)

Это запланировано на будущее; см. OpenBSD-current.

> >>root       866  0.0  0.4  2504 1260 ?        S    Sep22   0:07 /usr/sbin/sshd
> >>root      3414  0.0  0.6  5840 1776 ?        S    12:19   0:00 \_ /usr/sbin/sshd
> >
> >Нужен root для авторизации пользователей.
> >
> проясните пожалуйста
> 
> допустим я имею логин и пассворд пользователя (мб рута)
> 
> char *login="vasya";
> char *passwd="pupkin";
> разве этого недостаточно чтобы сделать программный su?

Авторизация - это не su (и не только по паролю).

> >>root      1346  0.0  0.4  3756 1108 ?        S    Sep22   0:00 squid -D
> >>squid     1348  0.0 18.5 49112 47584 ?       R    Sep22  12:21  \_ (squid) -D
> >>squid     1365  0.0  0.1  1228  268 ?        S    Sep22   0:01      \_ (unlinkd)
> >
> >Управляющий сервер - root;
> >все остальные - псевдопользователи.
> >В принципе, и управляющий сервер можно сконфигурировать работать с правами
> >псевдопользователя в chroot jail; при этом будет потеряна часть
> >функциональности.
> >В принципе, тут есть над чем поработать.
> >
> что в функциональности прокси может быть потеряно ?

Запуск вспомогательных программ, напр. фильтров.

> >>root      1393  0.0  0.1  1232  416 tty1     S    Sep22   0:00 /sbin/mingetty tty1
> >>root      1394  0.0  0.1  1232  416 tty2     S    Sep22   0:00 /sbin/mingetty tty2
> >>root      1395  0.0  0.1  1232  416 tty3     S    Sep22   0:00 /sbin/mingetty tty3
> >
> >Нужен CAP_SYS_TTY_CONFIG для vhangup() на терминал.
> >
> права доступа ?

Нет, в sys_vhangup стоит явная проверка на CAP_SYS_TTY_CONFIG.
В принципе, можно mingetty оставить только этот CAP...
Можно попробовать, но заметного выигрыша не будет.

> >>root      1882  0.0  0.5  4212 1504 ?        S    Sep22   0:00 httpd 
> >>apache   17381  0.0  0.6  4432 1732 ?        S    Sep29   0:00  \_ httpd 
> >>apache   17382  0.0  0.6  4432 1764 ?        S    Sep29   0:00  \_ httpd 
> >>apache   17383  0.0  0.6  4440 1748 ?        S    Sep29   0:00  \_ httpd 
> >>apache   17384  0.0  0.6  4444 1764 ?        S    Sep29   0:00  \_ httpd 
> >>apache   17444  0.0  0.6  4444 1760 ?        S    Sep29   0:00  \_ httpd 
> >>apache   17445  0.0  0.7  4456 1804 ?        S    Sep29   0:00  \_ httpd 
> >>apache   17895  0.0  0.6  4432 1736 ?        S    Sep29   0:00  \_ httpd 
> >>apache   17896  0.0  0.6  4444 1776 ?        S    Sep29   0:00  \_ httpd 
> >>apache   17917  0.0  0.6  4444 1784 ?        S    Sep29   0:00  \_ httpd 
> >>apache   20655  0.0  0.6  4432 1732 ?        S    Sep29   0:00  \_ httpd 
> >
> >Управляющий сервер - root;
> >все остальные - псевдопользователи.
> >В принципе, и управляющий сервер можно сконфигурировать работать с правами
> >псевдопользователя; при этом будет потеряна часть функциональности.
> >
> опять же какая часть ?
> сервер он вроде "сам по себе сервер" зачем ему рут ?
> только для того, чтобы сокеты открывать ?

Не только сокеты, но и дополнительные модули.


--
ldv

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

Re: [sisyphus] chroot

[Dmitry E. Oboukhov]

>
>
>>опять же какая часть ?
>>сервер он вроде "сам по себе сервер" зачем ему рут ?
>>только для того, чтобы сокеты открывать ?
>>    
>>
>
>Не только сокеты, но и дополнительные модули.
>
>  
>
вы два раза сослались на модули (выше я немножко потер)

и что дополнительные модули ?
они не могут быть загружены без рута? или эти модули
должны иметь доступ к чему-то ? в этом случае не модули,
а права доступа для конкретной софтины...

проясните еще раз, на примере скажем апача

вот его примерная функциональность:
1. сервер НТТР на 80-м порту
2. возможность исполнения программ связанных с этим сервером - а-ля ЦГИ итп
эти программы _отдельно_ должны оцениваться по безопасности и хотя-бы из-за
них апач не должен иметь рута
3. возможность работы в качестве прокси - не рассматриваем
4. что-то еще

ну да реально это все сложнее и навороченнее чем в этой схеме, но зачем 
рут ?

тоже самое и про прокси-сервер:
1. сервер на ХХХ порту
2. переадресовка запросов к серверу - проксе выше по уровню (или
непосредственно НТТР-серверу), возврат данных клиенту
3. всякий там фильтеринг - то есть разбор от кого пришел запрос,
запрос какой информации идет итд

зачем здесь рут ?

как мне написали выше - для открытия сокетов - я сегодня
загляну в доки и исходники вечером, но что-то очень не верится
мне в это...


ЗЫ: я не ожидал, что написав о том, что люди ставят программы двумя
способами - начну флейм на эту тему.
Писал я это в ответ на то, что сказали, что предложение расставлять
права неудачно для всех (не очень умных) админов, я же ответил,
что _для тех кто будет ставить из дистрибутива/репозитария это не
будет дополнительным геморроем_.

[sisyphus] Re: chroot [JT]

[Alexey Tourbin]

On Mon, Sep 23, 2002 at 04:03:59PM +0400, Dmitry E. Oboukhov wrote:
> >Это вы нас хотите в чем-то переубедить? Или мы вас? Оставьте.
> >
> все всех ;)

Видите ли, чтобы переубеждать, нужно иметь вес.
Во сколько вы оцениваете свой вес?

Re: [sisyphus] Re: chroot [JT]

[Dmitry E. Oboukhov]

Alexey Tourbin wrote:

>On Mon, Sep 23, 2002 at 04:03:59PM +0400, Dmitry E. Oboukhov wrote:
>  
>
>>>Это вы нас хотите в чем-то переубедить? Или мы вас? Оставьте.
>>>
>>>      
>>>
>>все всех ;)
>>    
>>
а Вы ?

[sisyphus] Re: chroot [JT]

[Alexey Tourbin]

On Tue, Oct 01, 2002 at 07:46:23PM +0400, Dmitry E. Oboukhov wrote:
> >>все всех ;)
> >>   
> >>
> а Вы ?

А я не стремлюсь никого переубеждать. Даже Вас. :)
Если мне что-то непонятно, я просто "спрашиваю".
Поэтому вопрос о моём весе не может быть для Вас актуальным.

PS: всё.

[sisyphus] Re: chroot [JT]

[Vitaly Ostanin]

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

Dmitry E. Oboukhov пишет:

<skipped/>

> а Вы ?

Это похоже на переход на личности, как и предыдущее письмо на эту 
тему - давайте в talk-room, pls.

<skipped/>

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

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

[sisyphus] accessfs and non-root socket()s < 1024 (was: chroot)

[Michael Shigorin]

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

нарушая свое же слово...

On Tue, Oct 01, 2002 at 12:57:47PM +0400, Dmitry E. Oboukhov wrote:
> сервер он вроде "сам по себе сервер" зачем ему рут ?
> только для того, чтобы сокеты открывать ?

Кстати: http://kt.zork.net/kernel-traffic/kt20020930_186.html#12

Возможно, полегчает и в этом направлении.

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

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