Поздравляю. Но, пользоваться буду - только под угрозой увольнения

Значит она не скоро рипнится, как ожидали.

Кто?

ROSA

Нет она не рипнется. Более того, скорее французская часть Mandriva рипнется, и разработка полностью перетечёт в Россию. Ура, товарищи!

Это будет полный провал.

Я не сомневаюсь, что сертификация будет пройдена. Другой вопрос, что де-факто это будет сырая и недоделанная система с вагоном глюков и левых пакетов, и аббревиатура LTS тут как-то не особо уместна.

Ну да, если разрабы в своей системе разобраться не могут.
Шпионы эту систему будут обходить стороной 

Ни один юникс не может быть сертифицирован по 1Г принципиально. Поскольку изначально, по своей концепции, не удовлетворяет руководящим документам, определяющим необходимые качества для этого уровня. А именно, например, для 1Г необходимо обеспечивать целостность программной среды следующим образом:
целостность программной среды обеспечивается использованием трансляторов с языков высокого уровня и отсутствием средств модификации объектного кода программ в процессе обработки и (или) хранения защищаемой информации;
То есть ни один скрипт на шелле, перле или питоне (на том, на чем и стоит весь юникс) не может быть пропущен в мир по 1Г. Далее:
должна осуществляться очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ и внешних накопителей. Очистка осуществляется однократной произвольной записью в освобождаемую область памяти, ранее использованную для хранения защищаемых данных (файлов);

И если твои системные библиотеки не обеспечивают такой очистки памяти, то тоже опаньки. А если обеспечивают, то прощай производительность компьютера. Он только и будет заниматься тем, что освобождаемую память рандомным мусором забивать.

Ну а на гостайну - там по руководящим документам вбита нереализуемая на обычных юниксах (на их файловых системах) модель Белла-Лападула, полномочный принцип контроля доступа.

Да откройте сайт ФСТЭК'а. Там всё есть. Просто надо очень четко отделять мух от котлет. Одно дело получить "сертификат", и совсем иное - соответствовать требованиям руководящих документов. Систем, имеющих бумажку много. Но вот насколько они реально соответсвуют требованиям - это вопрос совсем иной. Имею, например, наглость утверждать, что нет ни одной в России сертифицированной системы защиты информации полностью реализующую полномочные правила распределения доступа и полномочный контроль потоков информации. Но системы, сертифицированные для защиты обработки гостайны есть.

Есть там (в РД) откровенные хохмы. Например, класс 1Г (предназначен для систем с конфиденциальной, не гостайна, информацией). В нем определена очистка оперативной памяти путем однократной записи при её освобождении туда произвольной последовательности. А вот если гостайна, то класс 1В и память оперативную надо чистить более надежно, путем двухкратной записи туда произвольной последовательности.
Я не совсем понимаю, какую пользу, кроме снижения производительности, несет требовании повторной записи того же нуля в RAM. Если ноль записан, то и записан, и что там было до того - нет принципиальной возможности восстановить. Память это в том или ином исполнении триггер. И если его установить в какое либо состояние, то нет возможности определить состояние предыдущее.
Исторический экскурс. В свое время, когда в ходу были разнообразные дискеты "инженеры" предшественника ФСТЭК'а проявили глубинные познания в компьютерных технологиях и в своих руководящих документах определили, что информацию на учтеных дискетах  следует уничтожать путем двухкратного их форматирования. Так я на спор бутылку хорошего коньяка выиграл, подняв минут за пять с такой дважды форматированной дискеты всю информацию не имея никакого специализированного оборудования. Бутылку ту мне так и не отдали, зажали, но и на разные "ученые" их сборища приглашать перестали. Теперь имеем требование двухкратной записи в RAM.

Да ладно уж - трудитесь.

Вот такие тайны? 

На бумаге проблем нет. А вот на практике...
1. Обнуление. При любом realloc() и иже с ним необходимо писать произвольную последовательность в освобождаемый блок памяти. Термин "произвольная" я выделил неспроста. В РД это синоним термина случайная. Следовательно, для её генерации необходимо иметь сертифицированный генератор случайных чисел. Это штука не самая простая. И отберет от вычислителя свою долю вычислительных ресурсов. А то и специальной платы с диодом-датчиком белого шума потребует. Это раз. Второе - обнулять надо не только оперативную память, но и дисковые ресурсы. И вот ты даешь команду rm на какой-то гигабайтный файл размещенный в сети (для наглядности). Это значит, что его содержимое перед реальным удалением необходимо заменить случайной последовательнстью. Какой объем трафика сгенерируем? Сколько времени будет удаляться такой файл?
В оффтопике, кажется, есть опция принудительно затирания удаляемых файлов. И как производительно работает в этом режиме оффтпик?
А если задача интенсивно работает с временными файлами? К ним же тоже надо применять гарантированное затирание. Производительность ложится здесь на раз.

2 Про полномочку. Полномочный принцип распределения доступа подразумевает прежде всего, что из системы, где она включена нет выхода информации во внешние системы, где мандатного принципа не реализовано. Иначе будет возможно передать секретный документ на иной компьютер, где полномочка не реализована. На бумаге требование звучит красиво, но попробуем его (контроль потоков) реализовать на практике.
- Основа основ. Не реализовав её ничего не получим. Хранение меток конфиденциальности. Где их хранить для файлов? Где их хранить для таблиц баз данных, где их хранить для полей баз данных? Причем хранить так, чтобы любой процесс, обращающийся к информации не прошёл мимо этого фильтра? То есть, только через сопоставление полномочий пользователя (формы допуска) и меткой конфиденциальности и никогда иначе. Будем модифицировать файловую систему, чтобы в ней, в файловых дескрипторах, разместить метки конфиденциальности? Что это файл секретный, а это совсекретный, а этим - рыбу заворачивали... А как такое реализовать на уровне таблиц СУБД, того же MySQL или иной системы. Да так вписать, чтобы при любом коннекте любого пользователя из любой программы произошло сравнение меток конфиденциальности и уровня допуска пользователя. И чтобы это сравнение наложилось на матрицу доступа и по этому совокупному сравнению и принималось решение о допуске юзера к нужной таблице. Мандатный механизм не строится на матрице доступа (триадами rwx rwx rwx). Эти механизмы, полномочный и дискреционный должны быть независимы друг от друга. Полномочка на дискреционном механизме не строится и из него не выводится. Это полностью самостоятельная сущность.
Ну ладно, каким то малопонятным образом мы сие реализовали.    Идем дальше.
- Контроль потоков. Необходимо обеспечить, чтобы информация из источника, помеченного как секретный, не попала в цель, не имеющую соответствующую метку конфиденциальности. Принцип Белла-Лападула гласит, что пользователь, имеющий секретный допуск, не может писать информацию в несекретные файлы (но может оттуда читать без проблем) и не может читать из совсекретных файлов (писать туда может). То есть он может читать все файлы до (и включая) своего уровня конфиденциальности и писать только в файлы со (и включая) своего уровня конфиденциальности.
Вопрос простой - как пользователю, имеющему вторую форму (работа с документами сов.секретно) создать несекретный или секретный файл в системе, реализующей Белла-Лападула? Иными словами, как пользователю реализовать работу с документами, имеющими различный гриф секретности при реализации модели Белла-Лападула? Ведь он чаще работает с обычными документами (или ДСП), несколько реже с "секретно" и совсем редко с "Сов.секретно".
Далее разбираем ситуацию контроля потоков и назачения меток конфиденциальности:
- Все локально. Открыли секретный файл. Выделяем в нем блок с секретной информацией, заносим его в клипборд, переключаемся в иное окно, в терминал (который может быть запущен ранее) и там пишем тривиальное cat >> new.file (new.file - не помечен ничем). И вставляем там  из клипборда блок, взятый из первого файла.
После чего варианты:
1. Закрываем файл. Какая на нём должна автоматически проставится метка конфиденциальности? "Секретно"?
2. Затираем скопированный блок полностью и закрываем файл. Какую он должен получить метку конфиденциальности? Ведь хоть перенос туда и состоялся, но информация вычищена и файл её не содержит. У автомата, назначающего метки конфиденциальности   мозги на такую ситуацию не скособочит?
3. Не закрываем файл new.file, а еще раз выделяем уже в нем блок информации и через клипборд гоним его в третий терминал, где вставляем оный в иной документ. Очевидно, что этот новый третий документ должен получить метку конфиденциальности, соответствующую оригинальному файлу. А как это обеспечить, если таких меток на new.file, точнее, на соответствующем /dev/tty не образовалось. А если мы гоним инфу транзитом через буфера gedit?
Ответы на эти простые вопросы есть? Тут, кстати, есть еще одно неочевидное следствие. Проблема временных файлов и свопа. Если наша программа обрабатывает секретные данные и создает временные файлы, то они должны иметь тоже секретный статус. Соответственно хранилище сектретных tmp-файлов тоже должно приобрести метку секретно. А далее иная программа, работающая со своими несекретными данными, но так же пользующаяся механизмом tmp-файлов, создает временный файл, тот приобретает статус (по месту расположения) сектретно и вся наша несекретная инфа - автоматом секретится.
Идем далее:
- обмен с внешним миром. Нам надо послать нашу информацию в электронном виде так, чтобы на не потеряла на приемнике своих меток конфиденциальности. Мы можем переслать файло через "файлообменник" (файловый сервер на NFS, CIFS или иной), через FTP или напрямую получателю через ssh. При этом при передаче не должна потеряться информация об метках конфиденциальности. А если посылаем инфу по почте? Как здесь обеспечить сохранность меток? Далее - USB-флешки. Что с ними делать?

И это только первоначальный круг проблем при реализации модели Белла-Лападула.  Есть ответы, как реализовать это в точном соответствии с написанными требованиями, без технического лукавства, когда дискреционные групповые политики выдают за мендатный доступ???

Или проблем не видим?

Да пусть работают люди, от них там тоже немного зависит.