Здравствуйте, уважаемые читатели моего блога!
Сегодня я поделюсь с Вами очередной любопытной историей из опыта администрирования операционной системы 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
Можно было обойтись малой кровью: если есть логин-пароль на grub, в параметрах ядра поставить parsec.max_ilev=0 и беспрепятственно восстановить micdb для админа.
Согласен. Именно поэтому важно его менять своевременно и вести учёт паролей. Чтобы потом не извращаться.
Отличная статья! Очень увлекательно и познавательно
изложен материал.
Спасибо)!