Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

Re: lug-bg: Bind в chroot


  • Subject: Re: lug-bg: Bind в chroot
  • From: Georgi Chorbadzhiyski <gf@xxxxxxxxxxx>
  • Date: Fri, 18 Mar 2005 17:49:05 +0200
  • Organization: Unix Solutions Ltd. (http://unixsol.org)

Vasil Kolev wrote:
> On пт, 2005-03-18 at 16:58 +0200, Georgi Chorbadzhiyski wrote:
> 
>>Vasil Kolev wrote:
>>
>>>1) chroot() на какъвто и да е демон е дребна, не особено смислена мярка,
>>>която стана модна в един момент. Аз поне грам смисъл не виждам в това,
>>>при условие, че като счупиш демона, можеш да пускаш всякакъв свой код,
>>>т.е. да направиш т.нар. userland exec(), и да го превземеш. В момента
>>
>>Ако си root винаги можеш да се измъкнеш от chroot. Но ако нямаш root права,
>>измъкването е доста трудно да не кажа невъзможно ако нямаш достъп до fd,
>>което сочи извън chroot-а.
> 
> Не говоря за излизане - просто за пускане на един процес, дето слуша на
> един порт команди, и праща трафик от друг (както казах, разпращач на
> спам :) ). Фактически chroot-а е доста осакатена история, в BSD jail-а е

Не е оскатена, върши си добре работата. За това е chroot (Change filesystem
root), не е magic_secure_right_now (tm)

> малко по-добър като идея, ама май само в Plan9 има реален смисъл (ама
> там абсолютно всичко е файл, даже мрежовия им стек :) ).

Да в chroot мрежовите връзки не могат да се ограничат, за това трябва да се
ползва linux-vserver или нещо от сорта 9н (нещо по-така :) )

>>>както основно спамерите използват тия дупки за разпращане на поща, никви
>>>chroot()-ове или даже работа от други потребители не те спасяват. 
>>>(това е малко като non-exec stack-а за x86 - елементарно е експоитите да
>>>се прекодират с return-into-libc, вместо със изпълняване на код от
>>>стека).
>>
>>return-to-libc се решава с рандомизация на началният адрес на динамичните
>>библиотеки, когато се комбинира nonexec-stack|heap с рандомизация, нещата
>>стават доста по-трудни. Пак може да се напише exploit за дадена машина,
>>но той със сигурност няма да сработи на друга, дори и да е под абсолютно
>>същиото distro.
> 
> Не е точно така, хората изкараха един прекрасен paper за това колко
> малко рандомизация всъщност може да се направи на 32битови машини, то за
> това беше един от последните flame-ове в lkml, че един казваше, че 6-7
> бита за рандомизация са малко, а хората му обясниха, че и 12те постижими
> (или бяха 16?) бита пак не са нещо кой-знае колко страшно.

Дискусията я следях и наистина беше интересна. Все дори и 12бита рандомизация
повишават нивото. Есествено че не е "сребърният куршум", който решава с магическа
пръчка проблема. Сигурноста е въпрос на слоеве и когато всеки един от слоевете
добави малко от себе си, крайната система става доста сигурна.

Естествено че истинският проблем са бъгавите програми, който трябва да се
поправят, ама това няма да стане никога.

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================



 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.