[castle] read proc - Operation not permitted

[Stanislav Ievlev]

Marat Khairullin wrote:

>On Sun, 21 Oct 2001 19:18:37 +0300 (MSK)
>Marat Khairullin <xmm на rambler.ru> wrote:
>
>>kernel24-up-rsbac-2.4.7-alt2
>>
>>Есть задачка - uux должен запускать програмку /home/xxx/yyy
>>права на запуск, чтение xxx и yyy есть всем, но
>>uucp/Log:
>>uuxqt myhost myuser (2001-10-21 02:24:08.11 13710) ERROR: Not permitted to execute /home/xxx/yyy
>>
>
>Sorry. Тривиальная ошибка в имени исполняемого файла, - следствие ночных работ :),
>
><skip>
>
>>PS: Теперь не пускает никого кроме secoff'а:
>>Could not chdir to home directory /home/myuser: Operation not permitted
>>
>
>Вылечилось посредством rsbac_menu -> Switch module -> все в "off".
>
Обычно все же лечится просмотром журнала на предмет ругани и изменением 
соответствующей конфигурации, но это тоже выход.

>
>И переходом на не rsbac ядро.
>Надеюсь, что вернусь, когда будет нормальная документация по rsbac.
>
Нормальная документация будет в коробочной версии. Пока же доступна 
вполне нормальная документация на английском языке.
Основная проблема в изначальной сложности используемых моделей - надо 
очень хорошо понимать как они работают. Надеемся, нам удастся придумать 
хорошую методику обучения.

>
>Было бы здорово иметь soft_mode флаг не только для всего ядра, но и для каждой команды, когда ядро не в soft_mode.
>
Не совсем понял, что такое "каждая команда". Модули можно отключать по 
очереди (вы это и сделали).

>
>Не всегда есть возможность с имитировать сервачную конфигурацию на тестовой машине и заранее все отладить. 
>Пару раз была ситуация, когда после сбоя питания и из-за другой "железной" проблемы летела база rsbac.
>Не знаю как следит rsbac за целосностью своей базы, но гипотетически есть возможность получения бОльших прав.
>И не гипотетически, а наверняка - получаем отказ некоторых сервисов, что тоже не приятно если сервер в другом городе.
>Может стоит хранить данные rsbac'а в более надежном месте, чем файловая система
>
В принципе в базе RSBAC предусмотрено резервирование (правда я еще 
серьезно его не тестировал), так что полная потеря прав означает, что 
вам ОЧЕНЬ неповезло.
Боюсь от переезда базы все проблемы просто переедут в другое место и в 
другом качестве. А так ведь смогут слететь и обычные права доступа. У 
меня таким образом однажды полетели права по нескольким файловым 
системам - часть из которых была reiserfs, а часть ext2.Хуже того, права 
полетели в /var - потребовался не один день на восстановление.

По поводу хранения на другом сервере - вполне осуществимо, например так:
- сервер с некоторой базой
- клиентские машины синхронизируют расстановку прав с "большой" базой 
(надо сказать небанальная процедура, требующая наличия программы с 
ПОЛНЫМ доступом по файловой системе, что уже нехорошо)

Но посмотрите, опять возникают проблемы:
- Передача данных должна быть зашифрована (ФАПСИ?)
- Передача должна работать по принципу законченных транзакций 
(Полноценная СУБД?)
- Сервер опять-таки может вылететь из-за "железных" проблем со всей 
базой( Возвращаемся к пункту 1 ;) )

В общем, объем работ пока слишком велик для полного осуществления. Но 
будем надеется, что удасться додуматься до самого оптимального и 
недорогого решения - приглашаю всех к обсуждению.

>
>(в моем случае была reiserfs, хотя может именно это и подвело. К сожалению нет возможности
>ознакомиться с докладом `Журналируемые файловые системы для GNU/Linux: мифы и реальность`, а было бы интересно)
>одно дело потерять хидер какой-нибудь или даже может либу, но не особо важную и другое - только одну запись из rsbac.
>Для меня это стоило неделю работы, а фирме - кругленькую сумму.
>
Увы, но когда "железо" побеждает программы, всегда бывает нехорошо.

>
>Конечно, можно сказать, что - Замок-то бета
>
Все дело в том, что главная бетовость именно в RSBAC, а точнее в 
недостатке информации о нем. Я всегда всех предупреждал, что один 
неверный шаг, может закончится плачевно - все-таки основная задача RSBAC 
- конфиденциальность и в критических случаях он скорее перестанет 
пускать чем наоборот. Это серьезное оружие.
Тем не менее огромное Вам спасибо, за тестирование RSBAC - Ваши 
замечания несомненно найдут свое отражение в финале. Уже сейчас в Сизифе 
исправленны многое ошибки базовой конфигурации.

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

-------------------------------------------------------------
С наилучшими пожеланиями Станислав Иевлев.

>
>


----------- следущая часть -----------
3QЪ╕*^╝f╒≈В╡ы^Щ╚miхfz{lЪm4в]6КЩ]С]чоз╤ж°├g╖╤f