Здравствуйте, уважаемые читатели моего блога!

Сегодня я поделюсь с Вами очередной любопытной историей из опыта администрирования операционной системы Astra Linux SE 1.7.

Если мой блог помог Вам, вы можете поддержать меня любой суммой и мотивировать на написание новых заметок 🙂


Как-то раз ко мне обратился читатель моего блога с ничем не примечательной на первый взгляд проблемой. Звучала она так – “раньше рабочий стол был красный, теперь стал синий, также система выдаёт сообщение о вероятной проблеме со свободным местом на диске”.

Ну думаю – поставили низкий уровень целостности и не знают, как выбрать высокий. Решаю быстро проконсультировать, но оказывается, меню выбора режимов у пользователя не появляется.

Думаю, что просто заходят не с той учётной записи. Прошу выполнить команду:

cat /etc/passwd

И вижу единственного пользователя с 1001 uid. Очень странно. Интересно, а пользователь входит в astra-admin? Прошу выполнить команду:

sudo -i

Пользователь вводит пароль и входит в учётную запись root. Но без высокого уровня целостности это ничего нам, разумеется, не даёт.

Мне становится интересно, как же получилась такая ситуация. Разворачиваю виртуальную машину, захожу в пользователя, включенного в группу astra-admin, и пытаюсь изменить его высокий уровень целостности на низкий.

Получаю сообщение:

Логично, защита от “дурака” в действии. Но как же смогли поломать проблемную систему? Создаю другого администратора, устанавливаю низкий уровень целостности. После этого пытаюсь тут же снизить свой собственный уровень целостности до низкого. Опять получаю сообщение выше.

Мда… А если попробовать себя удалить? В точку. При удалении самого себя получаем следующее сообщение:

При этом пользователь остаётся живым, но целостность слетает до низкой.

Получается удаление самого себя обходит защиту от “дурака”. Прям вижу двух сотрудников ГК “Astra Linux”, которые говорят:

– А если они попробуют снизить себе МКЦ?
– Выведем сообщение и не дадим это сделать!
– А если пользователь попробует сам себя удалить?
– Не может быть – чушь какая-то!
– Согласен!

Собственно, как это получилось, я понял. Остался вопрос – что с этим делать?

На самом деле задача тривиальная – нужно зайти через загрузчик GRUB и создать файл пользователя /etc/parsec/micdb/1001 с содержимым “username:3f”. Иными словами, выполнить команду:

echo "username:3f" > /etc/parsec/micdb/1001

Если только у пользователя есть логин и пароль от GRUB 🙂

Говорю зайти в GRUB, пользователь ввёл пароль и всё… получилось. “Странно, что всё получилось так просто” – подумал я, и зря. Ввели init=/bin/bash, появилась оболочка, но не заработала клавиатура.

Первый раз такое вижу. Полазили в настойках NUMA BIOS – клавиатура не заработала. Бывают подобные проблемы из-за параметра USB Legacy, но это касается только USB клавиатур. Пользователь осматривает моноблок на наличие разъёма PS/2. Присылает фотографию:

Ну думаю, загрузимся с флешки, зайдём в режим восстановления и дело с концом.

Операционная система была установлена на моноблоке, в комплекте шёл диск с Astra Linux. Решили использовать его. Жду ответа от пользователя – присылает фотографию моноблока – DVD-ROM отсутствует :). Внешнего DVD-ROM’а тоже нет.

Ну ладно, загрузимся с флешки. Так как используем режим восстановления, подойдёт любая версия операционной системы. Скачали образ SE 1.6 (первый попавшийся) с интернета, записали на флешку с помощью Rufus, загрузились. Жду ответа от пользователя – присылает фотографию экрана.

Закрываю ладонью глаза – виной всему версия ядра (ранее писал об этом здесь). Нужен образ новее. Скачиваем SE 1.7, записываем на флешку и загружаемся.

Всё получается, заходим в “режим восстановления”, там монтируем корневую систему, выбираем устройство sda1 и ошибаемся, вместо корневой выбрали EFI раздел.

Ничего страшного, выходим, пользователь монтирует устройство sda2 и получает ошибку.

Со слов пользователя, на sda3 такая же ошибка. Устройства закончились :), но ничего страшного по-прежнему не случилось – монтируем sda1 и смотрим, какие разделы существуют в системе:

fdisk -l

Оказывается, что sda1 – EFI, sda2 – корневая файловая система (всё в одном), sda3 – SWAP.

Создаём точку монтирования и монтируем sda2 вручную:

mkdir /target1
mount /dev/sda2 /target1

И… О чудо – вручную всё проходит в штатном режиме. Пользователь вводит команду и создаёт высокий уровень целостности для своего пользователя:

echo 'username:3f' > /target1/etc/parsec/micdb/1001

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

Забавно, что до возникновения этой ситуации пользователь не имел дела с командной строкой операционной системы, но всё же смог под моим руководством восстановить работу Astra Linux (а после записался к психотерапевту – шутка :))

Всем хорошего дня! До новых встреч.

Александр Марухин
sandro331k@yandex.ru

6 комментариев для “Возвращаем права на высокий уровень целостности. Astra Linux SE 1.7.

  1. Можно было обойтись малой кровью: если есть логин-пароль на grub, в параметрах ядра поставить parsec.max_ilev=0 и беспрепятственно восстановить micdb для админа.

    1. Согласен. Именно поэтому важно его менять своевременно и вести учёт паролей. Чтобы потом не извращаться.

  2. Отличная статья! Очень увлекательно и познавательно
    изложен материал.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *