Почему работать всегда под root - это плохо?

Почему работать всегда под root - это плохо?

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

Что такое root и права доступа

Что такое root? Это привилегированный администратор системы. Помимо того, что вы указали логин и пароль администратора при установке, есть еще более высокий уровень - это root. Он создается автоматически при установке системы.

Директории в Linux имеют права доступа на системных разделах. Если вы обычный администратор (пользователь в группе sudo или wheel), то система не даст вам полномочий что-либо там изменить без повышения привилегий через команды sudo или su. Root имеет полный доступ ко всему в системе.

Astra Linux и мандатный контроль

Но в Astra Linux (релизы от Воронежа и выше до Смоленска) помимо обычных прав, необходимо учитывать еще и мандатный контроль. Здесь важно не путать две разные подсистемы:

Мандатный контроль доступа (МКД) - уровни конфиденциальности: 0 (несекретно), 1 (секретно), 2 (совершенно секретно), 3 (особой важности).

Мандатный контроль целостности (МКЦ) - уровни целостности от 0 до 63 (итого 64 уровня). Именно поэтому говорят про «63 уровень».

Допустим, на директорию /var установлены права root:root, владелец root и группа root. Завладев root-правами, вы не сможете там ничего сделать без соответствующего уровня целостности. Доступ к файлам будет только для root с нужным уровнем прав по контролю целостности.

Мой личный опыт поломки системы

Когда я начинал свое знакомство с Linux, я начал с Ubuntu. Я тогда не понимал, зачем нужно писать sudo каждый раз, когда удобней перейти сразу в root и выполнять все от его имени. Тогда я так и стал делать.

Я подумал, что авторы статей дураки, раз пишут sudo каждый раз, а я-то умнее - всего пару недель на Linux, но я лучше знаю. Итогом стала полностью сломанная система.

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

Практический пример: ООО «Ромашка»

Теперь давайте разберем на реальном примере практику. Возьмем маленькую бухгалтерию.

Вариант 1: все из-под root

Администратор залогинился как root и запускает скрипт установки:

root@office:~# ./install_crypto.sh

Скрипт распаковал файлы, создал конфиг и хранилище ключей:

root@office:~# ls -la /opt/cprocsp/
drwxr-xr-x 2 root root  4096 авг 17 10:00 bin
-rw------- 1 root root  2048 авг 17 10:00 config.ini   # <- только root читает!
drwx------ 2 root root  4096 авг 17 10:00 keys          # <- только root заходит!

Бухгалтер Мария садится за компьютер под своим пользователем maria:

maria@office:~$ /opt/cprocsp/bin/certmgr -list
bash: /opt/cprocsp/bin/certmgr: Permission denied

maria@office:~$ cat /opt/cprocsp/config.ini
cat: /opt/cprocsp/config.ini: Permission denied

Мария не видит сертификаты, не может подписать отчет. Бухгалтерия стоит. Администратору звонят каждые пять минут.

Вариант 2: та же установка, но через sudo

Администратор работает под своей учеткой admin:

admin@office:~$ sudo ./install_crypto.sh

Система повысила привилегии только на время скрипта. Но сам скрипт внутри раскладывает файлы правильно:

admin@office:~$ ls -la /opt/cprocsp/
drwxr-xr-x 2 root   root    4096 авг 17 10:00 bin
-rw-r--r-- 1 root   crypto  2048 авг 17 10:00 config.ini  #группа crypto -> чтение
drwxrwx--- 2 root   crypto  4096 авг 17 10:00 keys     #группа crypto -> чтение/запись

#Добавляем бухгалтеров в группу:
admin@office:~$ sudo usermod -aG crypto maria
admin@office:~$ sudo usermod -aG crypto olga

Бухгалтер Мария перелогинилась:

maria@office:~$ /opt/cprocsp/bin/certmgr -list
Найден 1 сертификат:
  Субъект: CN=Мария Иванова, ООО «Ромашка»
  Действителен до: 17.08.2027

maria@office:~$ #Подписывает отчет - все работает.

Что произошло?

Команда sudo и как она работает

Тут мы подошли к самому главному - команде sudo (Substitute User and Do, дословно «подменить пользователя и выполнить»). Исторически это расшифровывалось как «Superuser Do», но современная трактовка шире, так как sudo может выполнять команду от имени любого пользователя, не только root.

При выполнении команды sudo перед какой-то командой, там где необходимо, система сама, в автоматическом режиме повысит привилегии для записи файлов, конфигов и т.д. в те места, где нужны root-права.

Это порой бывает критично при работе программ, когда программа не может, к примеру, обратиться к локальной базе данных в виде SQLite или же применить конфиг для настройки.

Сравнение с Windows UAC

Стало сложно и думаете, что Windows лучше? Ошибаетесь, в Windows это тоже есть. Я думаю, многие видели всплывающее подтверждение администратора «да» или «нет» от UAC (User Account Control).

Только там у вас иллюзия выбора, где вас привели как большого начальника, дали вам бумаги на подпись и все. Вы не знаете, что там и как, вас просят подписать или отклонить. В Linux вы сами контролируете весь процесс и вправе вмешаться в него.

Разница в гранулярности: sudo повышает права на одну команду, UAC - на весь запускаемый процесс. В Windows вы нажимаете кнопку «Да» и не видите, что именно сейчас получит привилегии. В Linux вы пишете команду и точно знаете, какое действие выполняете с повышенными правами.

Резюме и чек-лист

Я всегда категорически против работы под root и бью по рукам тем горе-админам, которые это делают. Это очень мощный и в то же время тонкий инструмент, который нужно применять с полным осознанием своих действий и делать это хирургически.

Чек-лист безопасной работы:

1. Вхожу в систему под обычным пользователем.
2. Нужны права? → sudo <команда>
3. Никогда не использую sudo su - / sudo -i на рабочей машине.
4. После работы под root проверяю ls -la на созданные файлы.
5. На сервере прямой вход root по SSH отключн (PermitRootLogin no).

Когда можно работать под root?

Используйте всегда команду sudo, если это рабочая машина с другими пользователями, а вы ее администратор. Тем самым повышайте права только когда это требуется.

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

Как говорил один из моих руководителей:

«Бывает и палка стреляет»

Берегите свои системы и работайте безопасно!