Re: lug-bg: resource testing + rsbac test machine

[George Danchev <danchev@xxxxxxxxx>]

On Monday 06 December 2004 15:30, Skeleta wrote:
> George Danchev wrote:
> >On Tuesday 30 November 2004 15:05, Skeleta wrote:
> >
> >
> > ...
> >
> >Вчера имах възможност да поблъскам малко resource testing програмки на
> > една тестова машина с rsbac (е и ограничения от pam има). Ами почувствах
> > се като петокласник пред строгая учительница ;-) (в крайна сметка реших
> > да го отдам на това, че testing програмите ми не са били сериозни)
> >...
> >
> >ресурсите предоставяни от ядрото са известни и могат да бъдат контролирани
> > ;-)
>
> Да, така е, но този контрол в крайна сметка води до система, в която
> заделяш на всеки потребител фиксиран ресурс, като сумата от заделените
> ресурси трябва да е под 100% от общия ресурс на системата. Получава се
> нещо като разделяне на реалния компютър на няколко VM (виртуални
> машини), които са съществено по-слаби от реалния компютър. Това вече не
> е UNIX  в интуитивния смисъл на думата, а нещо по-ограничено.

Не вярвам ;-) 
Не разбирам какво имаш предвид под "UNIX  в интуитивния смисъл на думата" ? 
Както знаем UNIX е всяка операционна система която следва Single Unix 
Specification на The OpenGroup и POSIX.1 POSIX.2 на IEEE за portability & 
enhancements. Нещо повече дори:

IEEE Std 1003.1e is part of the POSIX series of standards. It defines security 
interfaces to open systems for access control lists, audit, separation of 
privilege (capabilities), mandatory access control, and information label 
mechanisms. This standard is stated in terms of its C binding.

IEEE Std 1003.2c is an amendment to IEEE Std 1003.2-1992. It defines security 
utilities to open systems for access control lists, separation of privilege 
(capabilities), mandatory access control, and information label mechanisms.

Fine-grained Mandatory Access Control не противоречи на SuSv1/2/3 и POSIX* 
standards.

Ето пример на UNIX Operating System с тези и може би по-големи възможности:

# Mandatory security and access labelling of all objects, e.g. files, 
processes, devices etc.
# Label integrity checking (e.g. maintenance of sensitivity labels when data 
is exported).
# Auditing of labelled objects.
# Mandatory access control for all operations.
# Ability to specify security level printed on human-readable output (e.g. 
printers).
# Ability to specify security level on any machine-readable output.
# Enhanced auditing.
# Enhanced protection of Operating System.
# Improved documentation.

http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EPL-93-008-A.html
http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EPL-95-001.html

Тук няма чувства и интуиция ;-)

> >>UNIX-подобните системи (стандартните реализации) делят ресурсите на две
> >>категории (root/user) и всичко дето е за юсерите, можеш да го изядеш
> >>сам, като по този начин блокирваш всички останали и те заспиват.
> >
> >Decretionary times ;-) Вече могат да се дефинират Roles (Role Based Access
> >Control), Types, Domains,  и една камара други неща. (apt-get install
> >selinux-doc, чети policy.pdf, module.pdf (цитират се директно kernel
> >internals и по някое време започва да те притиска нещо като менгеме откъм
> >тила ;-) и ще ти се объркат представите за Unix ;-)
> >Има и промени по userspace - daemons, new utils.
>
> И тази сложнотия може да предизвика още проблеми ...

остава да видим ;-)

Понякога се налага да се правят и сложни операции - например в авиацията, 
космонавтиката, различни видове транспортни и комуникационни и мониторингови 
задачи и т.н.

> > ...
> >
> >Policy може да се променя on-the-fly.
>
> Наистина можеш on-the-fly да пипаш лимитите, обаче трябва да има жив
> администратор, който да седи и да наблюдава кво се случва, а това вече е
> по-сложна и скъпа система, състояща се от човек+компютър. Моето мнение
> е, че всяка по-сложна policy политика също ще може да се надхитри с
> някаква бомба, само най-простата политика - на N усера да дадем по
> 1/N-та от ресурса (или подобна по простота) не може да се издъни.

И да, може би и не.

> >
> >това се оказа голям базик за rsbac ;-) просто този потребител си изчерпи
> >форковете, след което - форк resource temporary unavailable за него ;-),
> >другите потребители така и нищо не усетиха, че този се опитва да се
> >забавлява, освен админа с логовете.
>
> Опитай да сложиш и някаква сметка в безкраен цикъл на простата програма
> след fork-a. Ако нямаш лимит за cpu-ресурс, въпреки че броя процеси е
> лимитиран, процесора ще работи на 90% натоварване за тъпата програма.

Съгласен съм. И това ще разчоплиме ;-)  

> > ...
> >
> >за тестване на мрежовите ресурси са толкова много нещата, че страх ме
> >набира ;-)
> >...
> >Дай пример за по-тънко. Директно говори в код, за който има свободни
> >компилатори и/или интерпретатори. Хич не се шегувам ;-)
>
> Съжалявам, че не подкрепям приказките си с примери, но едната причина е,
> че съм стар и мързелив, втората - нямам машина за експерименти в
> момента.  Все пак ви предлагам (на който му е интересно) да пробва
> следните идеи: отваряне на максимално много listen sockets и генериране
> на трафик към тях; препълване на syslog със съобщения; голям трафик на
> TCP-порт към себе си, комбинирано с fork.
>
> Една добре администрирана система ще се справи с горните идеи,  но  може
> да се случи и пробив, ако не всичко е изпипано.
>
> Извинете още веднъж, че давам много приказка без примери !
>
> Не искам и като заяждане да ми тълкувате писмото, просто моят възглед е,
> че е по-лесно по-прости неща да се правят и да се декомпозират задачите,
> то затова е направен и Internet-а - на една машина да върви web-сървер,
> на друга SQL и пр., като всеки хост да се администрира така, че да си
> върши работата горе-долу добре. А който иска shell - да си го пуска на
> собствената машина.

а зависи за каква работа са впрегнати тези Unices. Най-малкото като build коне 
могат да бъдат назначени ;-)

Благодарение на Никола Антонов много набързо сетнахме една тестова шел машина 
с RSBAC. Понеже ни писна да го тестваме, решихме да го предоставим за 
свободно тестване. Задачата е да се намерят пропуски в самия RSBAC или нашата 
конфигурация (далеч сме от мисълта, че сме използвали всички възможности на 
RSBAC, понеже не всичко сме разучили до сега). 

Машината се използва като build host, като интересното в случая е да се 
изразходят системните й ресурсите от тестовите потребители така, че да бъде 
доведена до състояние на неработоспособност (за студен или топъл рестарт).

Неоснователно големи забавяния в работата на машината също е добре да бъдат 
докладвани, като се покажат програмите и начините с които се възпроизвежда 
това състояние. Под ресурси разбирайте памет, процесорно време, файлови 
дескриптори, процеси и каквото се сетите още. Предпочитаме ако намерите 
дупка в сигурността да ни я съобщите. 

Използвайте машината за компилации и стартиране на system resource 
exhausting приложения. Ще бъде на разположение няколко дни, така, че 
който иска да заповяда и тества, гледа, разучава и запознава с RSBAC 
в действие.

С rsbac_menu можете да разгледате нашата конфигурация и да се възползвате 
от евентуални пропуски в нея (е не може да я променяте).

Може да инсталираме и допълнителни компилатори, интерпретатори и библиотеки 
необходими за вашите тестове.

Нападането на други хостове от този е силно нежелателно и неконструктивно.

Машината е Celeron 366, 128 MB RAM + 512 swap, бавен диск.

логин детайли:

hostname:  logos-bg.net 
user/pass: testN/testN [N=1..5] 
(общо 25 едновременни логина)
ssh port:  8022

Понеже много хора ще могат да се логват с test* потребителите, то ако имате 
желание да се убедите, че те не пречат на другите потребители, можем да ви 
направим персонален акаунт и да ви изпратим потребителя и паролата по пощата. 
Ако ви се генерира ssh keys, най-добре е да ни изпратите публичния ключ.

Следва SELinux stay tuned ;-)

-- 
pub 4096R/0E4BD0AB  2003-03-18  <keyserver.bu.edu ; pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
============================================================================
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
============================================================================