[castle] Re: [castle] Несколько вопросов

[Stanislav Ievlev]

Igor Dobryninskiy wrote:

>  Hello, Stanislav.
>
>On Fri, 16 Nov 2001 10:18:15 +0300
>Stanislav Ievlev <inger на altlinux.ru> wrote:
>
>>>1. Зачем введено ограничение на количество RC Roles и RC Types? Для RC
>>>  Type FD 64 типа явно мало, да и 32 роли тоже как-то негусто.
>>>
>
>SI> Кроме того вряд ли в ближайшее время потребуется более 60 ролей и
>типов. 
>SI> В самой последней версии secfiles 6 ролей  и приблизительно столько же
>
>SI> типов уже перекрывают практически все нужды по тонкому разраничению 
>SI> доступа. Может быть их количество увеличится до  10 но вряд ли больше.
>
>SI> Если модель сделана корректно, то один тип(роль) будет использоваться 
>SI> для большого количества реальных объектов.
>
>SI> Но тем не менее, если сможете привести реальную задачу в которой Вам 
>SI> потребуется столь много ролей(типов) - возможно убедим автора
>увеличить 
>SI> лимит.
>
>  Постараюсь привести. Например, хостинг. Несколько десятков виртуальных
>вебсерверов обслуживает один apache. Клиенты обновляют контент по ftp.
>Желательно дать шелл с ограниченным набором команд (mysql, perl и т.п.).
>Причём, один клиент может поддерживать несколько сайтов и ему желательно
>делать это с одним логином.
>
>  Я вижу себе это так:
>1. Для каждого сайта заводится несколько RC Types (контент, скрипты и
>   т.д.).
>2. Для каждого клиента заводится отдельная RC Role, которой даются нужные
>   права только на RC types тех сайтов, которые клиент поддерживает.
>
Понятно - тут то и происходит основная "трата" ролей и типов. Что ж, 
вполне резонно. Поговорю c автором.

>
>3. Для apache заводится RC Role, которой даются нужные права на все RC
>   Types всех сайтов.
>4. Для ftp тоже нужно RC Role. (?)
>
>  Есть более простые варианты? При моём потребуется уйма RC Types... Или я
>не до конца въехал в идеологию и всё можно резко упростить?
>
Наверное можно - если расширить модель. Например за счет введения еще 
одного уровня - класс ролей.

>
>>>2. Можно ли задавать диапазон AUTH Capabilities? 
>>>
>
>SI> Можно. auth_set_cap FILE add /bin/login 400:65535
>SI> Посмотрите как в последнем secfiles проставлены ограничения на
>SI> /bin/login ;)
>
>  Спасибо. Непременно посмотрю.
>
>>>А то su - штука в жизни полезная,
>>>  но давать root'у возможность сделать su на secoff совершенно не
>>>  хочется.
>>>
>
>SI> В этом нет никакой необходимости. Вы первый, кому это понадобилось. 
>SI> Интересно зачем?
>
>  Что понадобилось? Не давать root'у права su на uid secoff? ;) Мою
>вышеотквоченную фразу следует понимать так: "хочу разрешить root'у делать
>su на все uid, кроме некоторых, но не знаю как". Теперь знаю, спасибо.
>
>SI> Более того, мы наоборот приложили все усилия чтобы такой переход был 
>SI> практически невозможен.
>
>  После установки Castle Beta3 su можно делать только на uid 101
>(cacheman). Так что, действительно, усилия приложены... ;)
>
;)

>
>
>>>3. Есть ли где-нибудь рекомендации по настройке безопасности сервисов,
>>>  поставляемых в дистрибутиве? Имеются в виду www, ftp, mysql и т.п. -
>>>  то, к чему нужно давать доступ снаружи.
>>>
>
>SI> Общие рекомендации очевидные - минимум привилегий ;)
>SI> Более точных очевидно нет - все зависит от конкретной задачи: В одном 
>SI> случае чем-то можно пренебречь за счет высоких требований к 
>SI> функциональности, а в других требуются максимальные ограничения пусть 
>SI> даже в ущерб удобству и производительности.
>
>  Я имел в виду нечто вроде HOWTO: "Сервис такой-то, для нормального
>функционирования требует такого-то и такого-то доступа к таким-то и
>таким-то объектам. Рекомендуем создать такие-то RC Roles с такими-то
>правами к таким-то RC Types." А то апачь, к примеру, и в /proc, и в /home,
>и в /etc/passwd лезет при запуске. Куда его обязательно нужно пускать, а
>куда можно и не пустить?
>
Возможно появится, но не скоро. Нужно набраться опыта построения 
подобных систем.
Возможно Ваш опыт пригодится... пишите.

>
>
>--
>  С уважением - Игорь Добрынинский, инженер
>  Архангельская телевизионная компания
>  +7 818 2207227, egor на atknet.ru
>
>_______________________________________________
>Castle mailing list
>Castle на altlinux.ru
>http://altlinux.ru/mailman/listinfo/castle
>


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