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

[Igor Dobryninskiy]

  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 тех сайтов, которые клиент поддерживает.
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