Здравствуйте, уважаемые читатели моего блога!
Сегодня я поделюсь с Вами очередной любопытной историей из опыта администрирования операционной системы 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