Бета тестирование дистрибутива ALT Linux Castle

Тестирование проходит все же дистрибутив в целом.
На следующей неделе появится новая бета, интересующихся приглашаем
в список рассылки.

ISO появится на зеркалах?

Да и рано говорить о впечатлениях.

Для каких таких серверов нужен этот RSBAC?
Приведите мне пример, пожалста... А я вам скажу как вашу проблему решить без RSBAC.
Идет? Кстати замерьте обязательно потери в производительности.

Хе, посмотрел список пакетиков. Господа, ну вот скажите тупому, зачем
на двери держать новейший замок, если в доме дырявые стены? Очень любопытно
смотрится использование blowfish для криптования паролей на фоне таких
вещей как bind, proftpd, sendmail и иже с ними. Нет слов. Вы это хотите
продавать?

2Аноним (от 2001-05-26 03:18:45.0): Вы бы, прежде чем делать подобные выводы, посмотрели бы в тот самый Bind или Sendmail, или Proftpd в этом дистрибутиве. Может все-таки не будем изображать знатоков, не зная предмета? Или Вы думаете, что, к примеру, Bind у всех одинаково собранный бывает? По названию определяете одинаковость?

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

Кого ты блин обмануть хочешь? Сколько денег ты ставишь на кон, если я сломаю
BIND твоей спецсборки? Прога, которая в среднем каждые 3 месяца светится на
багтреке с рут-эксплойтами... и ты хочешь здесь кому-то очки втирать на счет
того, что пара патчиков может решить проблему? Очнись, бедняга, твои глазки
давно не видели живого солнца.

я даже испугался... приведи тогда примеры более крутых(в плане секьюрности, безбагности) серверов DNS, SMTP и FTP. А то очень на панику банальную похоже...

2anonymous: Ty postav' hotja-by pervuyu beta Castle i poprobuy. A potom palcy kiday. Tam zhe ne zrya RSBAC v kachestve osnovnogo komponenta prisutstvuet. Davay, poprobuy cherez Bind v nem root-a poluchit', a potom dannye polzovateley vzyat', ili binarnik kakoy podmenit. Davay-davay.

Насколька я помню они вроде все "часто ломаемые" сервисы в chroot загоняют... Или я чтот не то помню?

To anonymous (*) (2001-05-27 03:09:19.0) Вот фраза с ихнего сайта:
"В дистрибутиве следующие серверы работают
chrooted: postfix, bind, MySQL, junkbuster. С помощью отработанной
технологии в дальнейшем планируется chroot'изация других серверов,
входящих в дистрибутив."
Почитал бы что ли вначале прежде чем кричать...

А уважаемые когда-нибудь слышали о том, что chroot пробивается?
Вы думали, что chroot это магическая такая шапка-невидимка от взлома?
OK, допустим взломщик не смог пробить chroot, но остановил ваш fucking service,
bind например. Опочки, все встало рачком. Кому нужен такой корпоративный
сервер? Все очень хотят пробиться на него, чтобы воспользоваться знаменитыми
blowfiыh паролямя, а не могут! Приехали.

Альтернативы всем этим прогам есть. Если те, кто разрабатывает якобы секьюрный
дистрибутив о них не знают, то отсюда следует...

За нахождение дырки в qmail некоторое время назад стояло вознагрождение -
миллион баксов. Никто не изъявил желания его забрать ;-)
Для сравнения, на BIND9 уже потрачено порядка 10 млн. баксов, но ни одна
душа еще не поставила и мятой пятерки против его секьюрности. Жалко пятерку ;-(
А мне жалко создателей горе-дистрибутивов, вернее их пользователей. Впрочем,
по Сеньке и шапка.

А мне еще кажется, что можно получив root на chrooted service, создать node (через mknod(2)) соотв. /dev/sda, а потом открыть это устройство и забить все нулями - это должно привести к потере всей информации. Или создать node, соотв. /dev/kmem и пописать в тот node что-нить нехорошее. Для служб, работающих от рута - это вроде как возможно, и никакой rsbac наверно не поможет. -V

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

Не, я думаю что Root на chroot сервисе не root на всей системе - это основная фишка RSBAC, а то что кривой service фиг защитишь - это верно. Единственное, что крах его ни как не должно повлиять на работу всей ситемы.

Игорь.

А чего не так с proftpd кроме последних багов с DoS? Поподробнее можно? Или ссылочку?

А как сo chrootщь работать не подскажете доки,?? а то маны как то не очень про него написан

Ну что ты отрицательно настроен против RSBAC я понял...

Пример... Ну давай расскажи мне как сделать без RSBAC
ограниченный доступ к данным на серваке, причем рут в первую
очередь должен быть ограничен?
Допустим _Босс_ совсем не хочет светить перед сисадмином свою
почту или базу с "черной" бухгалтерией, причем он не часто бывает
в офисе и вводить постоянно пароли он не собирается.

А я с помощью нехитрых пасов с бубном, RSBAC и криптованной
файловой системой с привязкой к ядру за нннное
количество бакинских енто сотворю! Причем от _Босса_ не требуется
быть ИТ спецом, он должен освоить пару секурных моделей + консоль
управления ентими моделями и все.

Производительность падает незначительно, это того стоит учитывая
цену железа.

А откуда ты возьмешь mknode в chroot, собственно? Я лично
его тебе туда не положу :)
RSBAC могет почти все, ИМХО отличная вещь для создания sandbox'ов %)

2 anonymous (*) (2001-05-28 09:34:40.0 :- есть такой маунт nodev ,
2anonymous (*) (2001-05-28 04:57:02. не 1 млн, а 1 тысячу , за qmail.
2игорь : причем тут RSBAC?

Для proftpd такое понятие как 'buffer overflow' - это как "Здравствуйте".
Вообще, любая программа, имеющая security tracks - это уже потенциальная
беда. Правильные с точки зрения security программы никогда не появляются
на в колонках securityfocus с самого рождения.

Про ограниченный доступ к данным на серваке без RSBAC.
Криптованную fs без RSBAC можно сделать наверное десятком различных
способов. Рута на таком сервере не должно быть, точнее он остается у твоего босса,
и пароль ему отдавать никому не нужно, впрочем как и бакинские енто. Нужно
просто дать парочку пиздюлин админу и заставить его сделать такую конфигурацию,
при которой рут не будет нужен совсем, в крайнем случае - sudo.
Что на настроенном офисном сервере есть такое, что тебе нужно изменять под рутом?
Если назовешь, то подскажу тебе, как избавиться от этой проблемы.

Да, кстати, про sendmail давно ничего не слышно, - хотел было я сказать,
как увидел это: Sendmail 8.11.4
Changes: A fix for a signal race condition and bugfixes for 8.11.3.
;-))))))

По пунктам:
1. RSBAC не делает криптованных ФС совсем - не для того он нужен.
2. Рута и нет :) Админ на офисный сервак и не лазит, если тока пропачить
софтину или ФС проверить на предмет заполнение... Но дело то не в этом!
А в том, что кул хацкер, несмотря на все титанические усилия админа,
гипотетически, может хакнуть сервак и получить рута. Вот в чем беда в
первую очередь, а не в недоверии к админу.
3. Почему тебе так не нравиться идея RSBAC ? У меня есть ощущение,
что ты из конторы конкурирующей с ALTLinux ...

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

Второй пункт не выдерживает критики. Делать на словах секьюрный дистрибутив и
заранее допускать возможность взлома? Сорри, это абсурд. Впрочем, я же
сказал, что заявления ребят из AltLinux писаны вилами по воде. То есть
посмотри, изначально никто даже мысли такой не допускает, что может существовать
дистрибутив, полностью защищенный от взлома. Тогда снимите с рекламных
лозунгов все упоминания о безопасности, и к вам никаких претензий не будет ;-)
Ну никто же не ругает красную шапку за отсутствие элементарной безопасности.

Каким образом кул хацкер может получить рута? Да именно через те поганые
проги о которых я писал выше! Да, я противник таких средств как RSBAC,
non-executable stack и т.д только потому, что они как наркотик снимают боль,
но лечат истинную болезнь. Еще раз повторюсь, с января 1996 года ни одному
кулхацкеру в мире не удалось заработать ни цента из тех 1000+500 баксов,
предложенных за нахождение дыр в qmail. Никто серьезно не тестировал RSBAC и
никто не может дать гарантии того, что пробив защиту кривого сервиса, хакер
не пробъет защиту RSBAC. А если пробъет, то вы об этом просто можете никогда
не узнать ;-)

Ага, терь понятно ты против состава дистра... Ну дык напиши/позвони
ребятам убеди их что "вот это и вот это" они делают неправильно!

Я лично как раз не допускаю _возможности_ создания _безопасного_ дистра,
безопасность у всех своя. Заявления ALTLinux это маркетинг и мне лично до
буя, что они пишут... мне нравится идея лежащая в основе дистра. И я попробую
результат их работы, есть мелкий шанс, что они сделали дистр который нужно
будет доводить не 3-4 дня (BCL), а пару-тройку часов.

Я как раз за openwall (non-executable stack) и за RSBAC.

А по поводу "Никто серьезно не тестировал RSBAC" здесь нужно было
добавить словечко "ИМХО" или "AFAIK", а то люди могут подумать недоброе :)

По-поводу qmail, я не спец по нему, но я подожду ката его будет юзать
побольше народу... тогда и увидим чего он стоит и с чем его можно кюшать :)

> А откуда ты возьмешь mknode в chroot, собственно? Я лично
> его тебе туда не положу :)
Там написано mknod(2) а не mknod(1) - то есть речь идет про системный вызов, а не программу /bin/mknod
Еще раз глянул доку на RSBAC - она действительное (!) не дает возможность заблокировать работу программы с портами устройств. Так что грош этим RSBAC и Castle цена после этого. Рутом никого пускать нельзя даже в chrooted jail!

"Делать на словах секьюрный дистрибутив и заранее допускать возможность взлома?" А если не допускать возможность взлома, то какой тогда это секурный дистрибутив??? :) Вы, батенька, мало представляете о чем говорите. Почитайте сначала литературки грамотной (хотя бы в "Желтую книгу" загляните), а потом уже в форуме распинайтесь. Стандартные права в юникс - давно морально устарели. По поводу chroot, да, сломать можно. Но если иметь рута. Но кто ж insecure service под рутом то пускает???

qmail жуе куча народа узает :-))) и все вроде довольны :-))

Кто? Где? На моём канале из пары десятков человек _никто_ не юзает!
(состояние на Втр Май 29 14:09:33 MSD 2001)

2hvv: Влад, так ведь никто и не думает пускать потенциального "грабителя" в chroot рутом!
Что касается mknod(2), то RSBAC имеет ADF-запрос CREATE, который непосредственно mknod перехватывает.
Что касается портов устройств -- неправда Ваша, ADF-запрос GET_STATUS_DATA прекрасно работает с SCD ioports, таким образом, open_port не пройдет незамеченным.
Источник: http://www.rsbac.org/targetsrequests.htm
/ AB

To AB: Хмм, тогда я жестоко заблуждался в RSBAC и Castle, сорри. Я понадеялся, что переводы док по RSBAC, недавно выложенные на altlinux.ru, достаточно полно его описывают - а в них про состав SCD (что io ports это SCD) - не написано (поэтому я решил, что работу с портами ограничить нельзя и в соответствии с выдвинутой гипотезой озвучил мысль что RSBAC - неполное решение). Так что виноваты переводчики док по RSBAC :)

To szh: При том, что под нем сервис бахнуть можно, но не ломонуть систему.

Игорь.

Поставьте нормальные сервисы и е$%^^те мозги себе и своим клиентам.

> А как сo chrootщь работать не подскажете доки,?? а то маны как то не очень про него написан

Подскажем :) Дружное "Ура!" Alex_IZA за его доку:
http://www.lug.irk.ru/docs/chroot.htm

> А как сo chrootщь работать не подскажете доки,?? а то маны как то не очень про него написан >Подскажем :) Дружное "Ура!" Alex_IZA за его доку: >http://www.lug.irk.ru/docs/chroot.htm вот спасибо :-))