ASA пишет:

>Hello community,
>
>Мне,   как  системному  администратору,  хочется  понять  точную
>разницу между словами "Мастер" и "Утес-К", т.к. сейчас я работаю
>на  как  раз  таком предприятии, где эта разница в будущем может
>оказаться существенной.
>
>Поэтому несколько вопросов "на засыпку":
>
>Соотношение между "Мастером" и "Утес-К" с математической точки
>зрения. То есть: 
>  Является ли множество пакетов "Мастера" тождественным множеству
>пакетов "Утес-К" (с точностью до количества пакетов и их
>контрольных сумм), и если: 
>  1) ответ: "да", то получается, что я могу свою установку
>    "Мастера" назвать "Утес-К" или нет? если могу, то при
>    установке пакетов из Сизифа я теряю это право или нет?
>
1) - ответ нет. Утес-К - это Master + Security updates

>  2) ответ "почти да" (то есть где-то заменены слова "Мастер" на
>    "Утес-К") - почему такое оказалось возможным, и что дальше
>    делать?
>  3) ответ - "нет" - то в чем же собственно различие (списки
>    различающихся пакетов)?
>
+ Во многих местах master заменено на Утес-К (это все-таки юридически 
другой продукт, и это не наше требование) и поэтому контрольные суммы 
отличаются. Соответственно превратить Master в _сертифицированный_ 
Утес-К не получится.

>
>Далее. После каких действий "Утес-К" перестает удовлетворять
>условиям сертификации:
>  - после обновления из Сизифа (или другие дистрибутивные
>      решения ALT Linux)?
>
Да

>  - после установки постороннего (т.е. от других производителей)
>      rpm-пакета? (ответ, очевидно, "да, перестает", но хотелось
>      бы понять, есть ли тут какие нибудь нюансы)
>
Ответ - не совсем - смотрите внизу ограничения по применению.

>  - после установки самосборного пакета (make install или
>      самостоятельное заворачивание в rpm)? Тут есть еще такой
>      нюанс: есть ли разница, если в rpm завернет либо
>      официальный разработчик ALT Linux Team (т.е. чел, имеющий
>      адрес @altlinux.ru), либо кто-то другой?
>
см. ниже

>  - после написания своего "hello, world!" (или другой
>      программы, написанной с нуля для нужд пользователей
>      системы) и помещения его (без создания пакета или с его
>      созданием): а) в /usr/bin; б) в /usr/local/bin
>
см. ниже.

>То есть, где проходит граница, превращающая "Утес-К" в "просто
>Линух", нарушающий требования сертификата?
>
см.ниже.

>
>Дополнительный   вопрос   ("на  суперприз"):  откатим  все  (или
>некоторые)  изменения,  на  которые в предыдущем вопросе был дан
>ответ  "да,  перестает"  - восстановится ли система до состояния
>"удовлетворяет   условиям"?   Если   нет,   то  какие  изменения
>допустимы для сохранения возможности восстановления?
>
>  
>
Часть вопросов освещена тут:
Ограничения по применению ЗИС "Утес-К"

    Установка, настройка, администрирование и выполнение всех работ по 
контролю за функционированием и безопасностью ЗИС "Утес-К" должны 
выполняться квалифицированными сотрудниками, прошедшими обучение на 
соответствующих учебных курсах.
    В случае интеграции ЗИС "Утес-К" в какую-либо сетевую инфраструктуру 
и организации работы ЗИС "Утес-К" в сети, подключение, администрирование 
и контроль безопасности системы должны выполняться квалифицированными 
сотрудниками, прошедшими обучение на учебных курсах, посвященных 
вопросам сетевой безопасности.
     На этапе эксплуатации ЗИС "Утес-К" должны быть предусмотрены 
организационно-технические процедуры по сопровождению программных 
продуктов, входящих в ЗИС "Утес-К".
    Серверные программные продукты сторонних производителей, 
устанавливаемые в ЗИС "Утес-К", должны запускаться с ограниченными 
правами доступа и должны быть сконфигурированы на работу в условиях 
ограниченного доступа к файловой системе (так называемый "chrooted 
enviroment").
    При эксплуатации ЗИС "Утес-К" не должен производиться запуск 
прикладного программного обеспечения от имени пользователя с 
административными правами доступа к системе.
    На компьютере с ЗИС "Утес-К" не должно быть других операционных систем.
    Должна быть исключена возможность загрузки системы с любых устройств 
компьютера (или по сети) кроме жесткого диска, на который установлена 
ЗИС "Утес-К". Выбор устройств первоначальной загрузки, изменение 
настроек BIOS должны быть закрыты паролем. Системный блок, клавиатура, 
монитор должны быть опечатаны, и иметь единую инвентарную нумерацию.
    При удалении пользователя из ЗИС "Утес-К" должны быть выполнены: 
блокировка учетной записи пользователя; анализ содержимого его файлов на 
предмет передачи прав владения другому пользователю либо уничтожения; 
удаление учетной записи пользователя из учетного файла.
    Должны быть предусмотрены организационно-технические меры для 
резервного хранения и восстановления информации пользователей ЗИС "Утес-К".
    При установке ЗИС "Утес-К" должны быть заданы пароли, как для 
администратора системы, так и для всех пользователей. Функциональные 
возможности "вход без пароля" и "пользователь по умолчанию" 
использоваться не должны.
    Доступ к системе через средство удаленного администрирования ssh для 
администратора должен быть закрыт. Действия по администрированию в 
данном случае должны выполняться через механизмы предоставляемые 
средствами su/sudo.
    Для выполнения аутентификации в ЗИС "Утес-К" должны быть 
использованы механизмы управления теневыми паролями TCB.
    Не допускается внесение изменений в компоненты КСЗ ЗИС "Утес-К". В 
случае необходимости модификации КСЗ ЗИС "Утес-К" проводится повторная 
сертификация.
    При функционировании ЗИС "Утес-К" должен быть запущен модуль 
регистрации событий доступа к объектам (protocol). В связи с большим 
объемом регистрационной информации, получаемой в процессе контроля 
доступа к объектам (файлам) необходимо провести тщательную настройку 
средств автоматического архивирования регистрационной информации (c 
помощью программы logrotate) и предусмотреть организационно-технические 
меры по ежедневному анализу регистрационной информации.
    При анализе записей аудита по использованию средств безопасного 
удаления учитывать, что имя удаляемого файла в регистрационных записях 
не будет соответствовать целевому имени файла. Это обусловлено 
механизмом работы программы безопасного удаления файлов (shred), где 
сначала файл открывается на запись, с ним производятся действия, 
изменяющие его содержимое (перезапись случайной информацией), затем 
переименование и удаление. Целевое имя файла удаляемого данным методом 
регистрируется в системных журналах не в качестве удаляемого файла 
(protocol on unlink), а в качестве открываемого (protocol on open).


Rgds,
Rider

P.S. В дальнейшем такие вопросы просьба отправлять на org@, т.к. в этом 
списке есть вероятность не получить ответ на подобный вопрос.