Почему в конфигурационных файлах пароли не хранятся в явном виде
Как правило, конфигурационный файл считывается программой при запуске, отражая, таким образом, ее состояние на момент старта. Изменения настроек работающей программы в конфигурационном файле , как правило, не отражаются. Тому есть несколько причин: не стоит превращать файл, изредка редактируемый пользователем, в файл, изменение которого происходит постоянно; не стоит держать конфигурационный файл всегда открытым; тяжело, изменяя файл автоматически, не испортить структуру комментариев (интерпретируемых не машиной, а пользователем) и т. д. Впрочем, многие утилиты, особенно использующие графическую среду, могут записывать настройки в файл по окончании работы. Большинство конфигурационных файлов весьма удобно редактировать вручную, с помощью Vi или Emacs (для файлов, более или менее похожих, используется общая подсветка синтаксиса , а для наиболее популярных существуют и собственные варианты подсветки).
В /etc хранятся настройки системных служб, в том числе настройки по умолчанию, настройки по умолчанию пользовательских утилит, профили командных интерпретаторов, а также настройки, используемые в процессе загрузки системы (например, modules.conf ). Там же располагаются и стартовые сценарии , о которых рассказано в лекции 10. Чего не стоит искать в /etc , так это разнообразных примеров настройки той или иной службы. Считается, что пример – это часть документации, и их следует помещать, например, в /usr/share/doc/название_службы/examples .
Файлы, имеющие отношение к процессу досистемной загрузки , обычно лежат не там, а в /boot ; это стоит иметь в виду, так как /boot/ grub /menu.lst – тоже часть профиля системы, хотя и довольно специфическая. В профиль системы входит содержимое каталогов etc из так называемых "песочниц", расположенных обычно в /var/lib .
Смысл термина "песочница" вот в чем. В Linux есть замечательный системный вызов chroot() и использующая его утилита chroot , формат командной строки которой chroot каталог команда . Эта утилита запускает команду , изменив окружение таким образом, что та считает каталог корневым. Соответственно, все подкаталоги каталога представляются команде каталогами первого уровня вложенности, и т. д. Если необходимо во что бы то ни стало ограничить область действия некоторой утилиты (например, по причине ее небезопасности), можно запускать ее с помощью chroot . Тогда, даже имея права суперпользователя, эта утилита получит доступ только к каталогу и его подкаталогам, а /etc и прочие важные части системы окажутся в неприкосновенности. Сам каталог как раз и играет роль "песочницы", в которую утилиту "пустили поиграть", позволяя вытворять что угодно. Часто бывает, что в "песочнице" есть и свой каталог etc , содержащий необходимые для запуска утилиты (или системной службы) настройки. Вот этот-то etc из "песочницы" также входит в список каталогов, хранящих профиль системы.
В /etc могут находиться не только файлы, но и подкаталоги (особенно в стиле " .d ") и целые поддеревья каталогов. Например, в некоторых дистрибутивах Linux используется подкаталог /etc/sysconfig . Этот каталог создается и заполняется файлами при установке системы или при запуске специального "конфигуратора" – программы-кудесника, задающей наводящие вопросы. Некоторые стартовые сценарии , использующие полученные настройки, также лежат в этом каталоге или его подкаталогах. Если в системе есть каталог /etc/sysconfig , там должны оказаться настройки, относящиеся не к самим службам или утилитам, а к способу их запуска при загрузке, а также языковые и сетевые настройки, тип мыши и т. д.
Подсистема учетных записей
Несколько конфигурационных файлов и способы работы с ними заслуживают отдельного рассмотрения. В первую очередь Мефодий заинтересовался системой учетных записей, о которой упоминалось сразу в нескольких предыдущих лекциях. Итак, существует два файла, доступных для чтения всем пользователям: /etc/passwd , хранящий учетные данные пользователей, и /etc/group , определяющий членство пользователей в группах (во всех, кроме группы по умолчанию):
Оба файла состоят из строк, поля которых разделяются двоеточиями. В файле passwd – семь полей. Первое из них определяет входное имя пользователя – то самое, что вводится в ответ на " login :". Второе поле в ранних версиях UNIX использовалось для хранения ключа пароля . В Linux пользовательские пароли не хранятся нигде – ни в явном виде, ни в зашифрованном. Вместо этого хранится ключ (hash) пароля – комбинация символов, однозначно соответствующая паролю, из которой, однако, сам пароль получить нельзя. Иными словами, существует алгоритм превращения пароля в ключ , а алгоритма превращения ключа в пароль нет. Когда пользователь регистрируется в системе, из введенного им пароля изготавливается еще один ключ . Если он совпадает с тем, что хранится в учетной записи, значит, пароль правильный.
Авторы UNIX предполагали, что, раз пароль из ключа получить нельзя, ключ можно выставлять на всеобщее обозрение, однако выяснилось, что, узнав ключ , пароль можно попросту подобрать на очень мощной машине или в предположении, что пароль – это английское слово, год рождения, имя любимой кошки и т. п. Если подбор пароля сопровождается неудачными попытками входа в систему, это отражается в системных журналах и может быть легко замечено. А завладев ключом , злоумышленник сможет заняться подбором пароля втихомолку на каком-нибудь суперкомпьютере. В конце концов, ключ не нужен никому, кроме подсистемы идентификации , поэтому его вместе с другими полями учетной записи, о которых всем знать не обязательно, из /etc/passwd перенесли в "теневой" файл учетных записей – /etc/shadow . На месте ключа в Linux должна быть буква " x "; если там стоит что-то другое, идентификация пользователя не сработает, и он не сможет войти в систему.
Третье и четвертое поля passwd – идентификатор пользователя и идентификатор группы по умолчанию . Как уже говорилось в лекции 6, именно идентификатор пользователя , а не его входное имя , однозначно определяет пользователя в системе и его права. Можно создать несколько учетных записей с одинаковыми UID, которые различаются другими полями. Тогда при регистрации в системе под именами из этих записей пользователи могут получать разные домашние каталоги и командные оболочки, разное членство в группах, но иметь один и тот же UID. Пятое поле отводится под "полное имя" пользователя; это единственное поле passwd , содержимое которого ни на что не влияет. Наконец, шестое и седьмое поля содержат домашний каталог и стартовый командный интерпретатор пользователя. Если седьмое поле пусто, подразумевается /bin/sh , а если его содержимое не встречается в файле /etc/shells , содержащем допустимые командные интерпретаторы, неизбежны трудности при идентификации пользователя.
Строки файла /etc/group состоят из четырех полей, причем второе – ключ группового пароля – обычно не используется. Первое поле – это имя группы, третье – это идентификатор группы , а четвертое – это список входных имен пользователей, которые в эту группу входят (более точно – для которых эта группа является дополнительной, так как группа по умолчанию указывается в /etc/passwd , хотя никто не мешает продублировать группу по умолчанию и в /etc/group ). Таким образом, определение членства пользователя в группах зависит не от его UID, а от входного имени .
Упомянутый выше файл /etc/shadow , доступ к которому имеет только суперпользователь, также состоит из полей, разделяемых двоеточиями. Помимо входного имени и ключа пароля там указываются различные временные характеристики учетной записи: нижняя и верхняя граница времени жизни пароля, самой учетной записи, дата последнего изменения и т. п. Ключ пароля (второе поле) указывается в одном из поддерживаемых форматов, а если формат не опознан, вся учетная запись считается недействительной. Поэтому один из способов запретить регистрацию пользователя в системе – добавить один символ (например, " !") прямо в поле ключа , отчего все поле становится синтаксически неправильным. Вновь разрешить пользователю входить в систему можно, удалив из поля лишний символ. Именно так работает (с ключами " -L ", lock, и " -U ", unlock) утилита usermod , изменяющая учетную запись. С помощью этой утилиты можно отредактировать и все остальные поля как passwd , так и shadow .
Добавить и удалить пользователя или группу можно с помощью утилит useradd , userdel , groupadd и groupdel соответственно. Не стоит пользоваться текстовым редактором, так как он не гарантирует атомарности операции добавления/удаления, хотя бы потому, что изменению подлежат сразу два файла – passwd и shadow . Даже если необходимо отредактировать /etc/passwd или /etc/group (например, для добавления пользователя в группу или удаления его оттуда), стоит запускать не просто редактор, а vipw или vigr (именно их поведение, позволяющее соблюсти атомарность , копирует утилита visudo , описанная ранее):
Здесь был добавлен пользователь incognito , группа по умолчанию – users, член групп proc и cdrom , полное имя – "Incognito". Стоит заметить, что пароль для этой учетной записи установлен не был (чтобы создать пароль, стоило запустить команду passwd incognito ), и, даже если бы пользователя тут же не удалили ( userdel -r удаляет также и домашний каталог , и почтовый ящик), зарегистрироваться в системе под именем incognito было бы все равно невозможно.
Как вывести свою систему на новый уровень безопасности с модулями python-gnupg и getpass4.
Изображение : freeGraphicToday, via Pixabay. CC0.
В условиях растущих требований к безопасности создание и хранение паролей может вызвать вопросы не только для пользователей, но и у разработчиков и системных администраторов. Специалисты и другие осведомлённые люди знают, что пароли нужно хранить в зашифрованном виде. Уже на этапе ввода символы пароля нужно скрывать от любых глаз (даже от того человека, который его вводит). Всегда ли мы можем выполнить хотя бы эти требования?
Я единственный пользователь своего ноутбука, а на его борту крутится ОС семейства Linux. Поэтому меня не беспокоят пользователи, которые могут случайно или неслучайно посмотреть мои конфигурационные файлы, работая на этом же компьютере. Я решил заморочиться и повысить безопасность своего личного ноутбука, и на то есть свои причины. Да, я шифрую свой домашний каталог, но как только вхожу в систему, любой пароль, хранящийся в виде простого текста в файле конфигурации, потенциально может быть уязвим для чересчур любопытных глаз.
К тому же, я использую почтовый клиент Mutt. Он позволяет мне читать и составлять электронные письма прямо в Linux-терминале. Мне удобно, мне нравится. Правда, ему нужно, чтобы я хранил пароль в файле конфигурации (.mutt), либо всё время вводил пароль в интерактивном режиме. Поэтому я ограничил права доступа к моему конфигурационному файлу Mutt, чтобы его мог видеть только я.
Но есть ещё один важный момент: я периодически пишу технические статьи, составляю туториалы, помогаю людям в сообществе и публикую много своего кода в общедоступных репозиториях, публикую скриншоты своего экрана, часто показываю что-то на примере своей рабочей системы. Если по недосмотру меня угораздит засветить в Интернете (или где-то ещё) данные (и в том числе пароли) из моих конфигурационных файлов, это бросит неприятную тень на мою репутацию и безопасность. Так что надо подстраховаться.
Ну и, если вдруг злоумышленник завладеет моим ноутбуком или каким-то другим образом получит доступ в систему, он не сможет получить мой пароль без боя, просто запустив cat для просмотра логов и конфигов.
У меня получился вот такой скрипт для создания пароля с невидимым вводом и расшифровкой:
Сохраните файл как password_prompt.py, если хотите попробовать скрипт у себя. Если вместе с ним вы хотите использовать offlineimap, укажите в конфигурационном файле .offlineimaprc имя и путь к скрипту с паролем (у меня это ~/.mutt/password_prompt.py). Правда, там нужно сделать ещё кое-что, но об этом позже.
2.3. /etc/default/
Исторически конфигурационные файлы в папке /etc/default/ содержали настройки сервисов/программ-демонов для их использования с системами инициализации, например upstart. Однако с появлением systemd эта папка стала использоваться в основном для настроек приложений пользовательского пространства.
Система не перезаписывает файлы в папке /etc/default/ . А значит, как только мы настроили там поведение приложений, оно не изменится при обновлении системы.
4. Заключение
В этой статье мы рассмотрели два типа конфигурационных файлов, которые используются в Linux, и узнали, где их найти.
Кроме того, заглянули в наиболее распространённые папки для хранения конфигурационных файлов и выяснили, как более старые и новые приложения работают с пользовательскими настройками.
Поскольку ОС Linux не налагает ограничений на эти конфигурационные файлы, их синтаксис может быть самым разным. Но если взять на себя труд и хоть немного в них разобраться, знание конфигурационных файлов освобождает от ограничений пользовательских интерфейсов, предназначенных для новичков.
Как правило, конфигурационный файл считывается программой при запуске, отражая, таким образом, ее состояние на момент старта. Изменения настроек работающей программы в конфигурационном файле , как правило, не отражаются. Тому есть несколько причин: не стоит превращать файл, изредка редактируемый пользователем, в файл, изменение которого происходит постоянно; не стоит держать конфигурационный файл всегда открытым; тяжело, изменяя файл автоматически, не испортить структуру комментариев (интерпретируемых не машиной, а пользователем) и т. д. Впрочем, многие утилиты, особенно использующие графическую среду, могут записывать настройки в файл по окончании работы. Большинство конфигурационных файлов весьма удобно редактировать вручную, с помощью Vi или Emacs (для файлов, более или менее похожих, используется общая подсветка синтаксиса , а для наиболее популярных существуют и собственные варианты подсветки).
В /etc хранятся настройки системных служб, в том числе настройки по умолчанию, настройки по умолчанию пользовательских утилит, профили командных интерпретаторов, а также настройки, используемые в процессе загрузки системы (например, modules.conf ). Там же располагаются и стартовые сценарии , о которых рассказано в лекции 10. Чего не стоит искать в /etc , так это разнообразных примеров настройки той или иной службы. Считается, что пример – это часть документации, и их следует помещать, например, в /usr/share/doc/название_службы/examples .
Файлы, имеющие отношение к процессу досистемной загрузки , обычно лежат не там, а в /boot ; это стоит иметь в виду, так как /boot/ grub /menu.lst – тоже часть профиля системы, хотя и довольно специфическая. В профиль системы входит содержимое каталогов etc из так называемых "песочниц", расположенных обычно в /var/lib .
Смысл термина "песочница" вот в чем. В Linux есть замечательный системный вызов chroot() и использующая его утилита chroot , формат командной строки которой chroot каталог команда . Эта утилита запускает команду , изменив окружение таким образом, что та считает каталог корневым. Соответственно, все подкаталоги каталога представляются команде каталогами первого уровня вложенности, и т. д. Если необходимо во что бы то ни стало ограничить область действия некоторой утилиты (например, по причине ее небезопасности), можно запускать ее с помощью chroot . Тогда, даже имея права суперпользователя, эта утилита получит доступ только к каталогу и его подкаталогам, а /etc и прочие важные части системы окажутся в неприкосновенности. Сам каталог как раз и играет роль "песочницы", в которую утилиту "пустили поиграть", позволяя вытворять что угодно. Часто бывает, что в "песочнице" есть и свой каталог etc , содержащий необходимые для запуска утилиты (или системной службы) настройки. Вот этот-то etc из "песочницы" также входит в список каталогов, хранящих профиль системы.
В /etc могут находиться не только файлы, но и подкаталоги (особенно в стиле " .d ") и целые поддеревья каталогов. Например, в некоторых дистрибутивах Linux используется подкаталог /etc/sysconfig . Этот каталог создается и заполняется файлами при установке системы или при запуске специального "конфигуратора" – программы-кудесника, задающей наводящие вопросы. Некоторые стартовые сценарии , использующие полученные настройки, также лежат в этом каталоге или его подкаталогах. Если в системе есть каталог /etc/sysconfig , там должны оказаться настройки, относящиеся не к самим службам или утилитам, а к способу их запуска при загрузке, а также языковые и сетевые настройки, тип мыши и т. д.
Подсистема учетных записей
Несколько конфигурационных файлов и способы работы с ними заслуживают отдельного рассмотрения. В первую очередь Мефодий заинтересовался системой учетных записей, о которой упоминалось сразу в нескольких предыдущих лекциях. Итак, существует два файла, доступных для чтения всем пользователям: /etc/passwd , хранящий учетные данные пользователей, и /etc/group , определяющий членство пользователей в группах (во всех, кроме группы по умолчанию):
Оба файла состоят из строк, поля которых разделяются двоеточиями. В файле passwd – семь полей. Первое из них определяет входное имя пользователя – то самое, что вводится в ответ на " login :". Второе поле в ранних версиях UNIX использовалось для хранения ключа пароля . В Linux пользовательские пароли не хранятся нигде – ни в явном виде, ни в зашифрованном. Вместо этого хранится ключ (hash) пароля – комбинация символов, однозначно соответствующая паролю, из которой, однако, сам пароль получить нельзя. Иными словами, существует алгоритм превращения пароля в ключ , а алгоритма превращения ключа в пароль нет. Когда пользователь регистрируется в системе, из введенного им пароля изготавливается еще один ключ . Если он совпадает с тем, что хранится в учетной записи, значит, пароль правильный.
Авторы UNIX предполагали, что, раз пароль из ключа получить нельзя, ключ можно выставлять на всеобщее обозрение, однако выяснилось, что, узнав ключ , пароль можно попросту подобрать на очень мощной машине или в предположении, что пароль – это английское слово, год рождения, имя любимой кошки и т. п. Если подбор пароля сопровождается неудачными попытками входа в систему, это отражается в системных журналах и может быть легко замечено. А завладев ключом , злоумышленник сможет заняться подбором пароля втихомолку на каком-нибудь суперкомпьютере. В конце концов, ключ не нужен никому, кроме подсистемы идентификации , поэтому его вместе с другими полями учетной записи, о которых всем знать не обязательно, из /etc/passwd перенесли в "теневой" файл учетных записей – /etc/shadow . На месте ключа в Linux должна быть буква " x "; если там стоит что-то другое, идентификация пользователя не сработает, и он не сможет войти в систему.
Третье и четвертое поля passwd – идентификатор пользователя и идентификатор группы по умолчанию . Как уже говорилось в лекции 6, именно идентификатор пользователя , а не его входное имя , однозначно определяет пользователя в системе и его права. Можно создать несколько учетных записей с одинаковыми UID, которые различаются другими полями. Тогда при регистрации в системе под именами из этих записей пользователи могут получать разные домашние каталоги и командные оболочки, разное членство в группах, но иметь один и тот же UID. Пятое поле отводится под "полное имя" пользователя; это единственное поле passwd , содержимое которого ни на что не влияет. Наконец, шестое и седьмое поля содержат домашний каталог и стартовый командный интерпретатор пользователя. Если седьмое поле пусто, подразумевается /bin/sh , а если его содержимое не встречается в файле /etc/shells , содержащем допустимые командные интерпретаторы, неизбежны трудности при идентификации пользователя.
Строки файла /etc/group состоят из четырех полей, причем второе – ключ группового пароля – обычно не используется. Первое поле – это имя группы, третье – это идентификатор группы , а четвертое – это список входных имен пользователей, которые в эту группу входят (более точно – для которых эта группа является дополнительной, так как группа по умолчанию указывается в /etc/passwd , хотя никто не мешает продублировать группу по умолчанию и в /etc/group ). Таким образом, определение членства пользователя в группах зависит не от его UID, а от входного имени .
Упомянутый выше файл /etc/shadow , доступ к которому имеет только суперпользователь, также состоит из полей, разделяемых двоеточиями. Помимо входного имени и ключа пароля там указываются различные временные характеристики учетной записи: нижняя и верхняя граница времени жизни пароля, самой учетной записи, дата последнего изменения и т. п. Ключ пароля (второе поле) указывается в одном из поддерживаемых форматов, а если формат не опознан, вся учетная запись считается недействительной. Поэтому один из способов запретить регистрацию пользователя в системе – добавить один символ (например, " !") прямо в поле ключа , отчего все поле становится синтаксически неправильным. Вновь разрешить пользователю входить в систему можно, удалив из поля лишний символ. Именно так работает (с ключами " -L ", lock, и " -U ", unlock) утилита usermod , изменяющая учетную запись. С помощью этой утилиты можно отредактировать и все остальные поля как passwd , так и shadow .
Добавить и удалить пользователя или группу можно с помощью утилит useradd , userdel , groupadd и groupdel соответственно. Не стоит пользоваться текстовым редактором, так как он не гарантирует атомарности операции добавления/удаления, хотя бы потому, что изменению подлежат сразу два файла – passwd и shadow . Даже если необходимо отредактировать /etc/passwd или /etc/group (например, для добавления пользователя в группу или удаления его оттуда), стоит запускать не просто редактор, а vipw или vigr (именно их поведение, позволяющее соблюсти атомарность , копирует утилита visudo , описанная ранее):
Здесь был добавлен пользователь incognito , группа по умолчанию – users, член групп proc и cdrom , полное имя – "Incognito". Стоит заметить, что пароль для этой учетной записи установлен не был (чтобы создать пароль, стоило запустить команду passwd incognito ), и, даже если бы пользователя тут же не удалили ( userdel -r удаляет также и домашний каталог , и почтовый ящик), зарегистрироваться в системе под именем incognito было бы все равно невозможно.
Как правило, конфигурационный файл считывается программой при запуске, отражая, таким образом, ее состояние на момент старта. Изменения настроек работающей программы в конфигурационном файле , как правило, не отражаются. Тому есть несколько причин: не стоит превращать файл, изредка редактируемый пользователем, в файл, изменение которого происходит постоянно; не стоит держать конфигурационный файл всегда открытым; тяжело, изменяя файл автоматически, не испортить структуру комментариев (интерпретируемых не машиной, а пользователем) и т. д. Впрочем, многие утилиты, особенно использующие графическую среду, могут записывать настройки в файл по окончании работы. Большинство конфигурационных файлов весьма удобно редактировать вручную, с помощью Vi или Emacs (для файлов, более или менее похожих, используется общая подсветка синтаксиса , а для наиболее популярных существуют и собственные варианты подсветки).
В /etc хранятся настройки системных служб, в том числе настройки по умолчанию, настройки по умолчанию пользовательских утилит, профили командных интерпретаторов, а также настройки, используемые в процессе загрузки системы (например, modules.conf ). Там же располагаются и стартовые сценарии , о которых рассказано в лекции 10. Чего не стоит искать в /etc , так это разнообразных примеров настройки той или иной службы. Считается, что пример – это часть документации, и их следует помещать, например, в /usr/share/doc/название_службы/examples .
Файлы, имеющие отношение к процессу досистемной загрузки , обычно лежат не там, а в /boot ; это стоит иметь в виду, так как /boot/ grub /menu.lst – тоже часть профиля системы, хотя и довольно специфическая. В профиль системы входит содержимое каталогов etc из так называемых "песочниц", расположенных обычно в /var/lib .
Смысл термина "песочница" вот в чем. В Linux есть замечательный системный вызов chroot() и использующая его утилита chroot , формат командной строки которой chroot каталог команда . Эта утилита запускает команду , изменив окружение таким образом, что та считает каталог корневым. Соответственно, все подкаталоги каталога представляются команде каталогами первого уровня вложенности, и т. д. Если необходимо во что бы то ни стало ограничить область действия некоторой утилиты (например, по причине ее небезопасности), можно запускать ее с помощью chroot . Тогда, даже имея права суперпользователя, эта утилита получит доступ только к каталогу и его подкаталогам, а /etc и прочие важные части системы окажутся в неприкосновенности. Сам каталог как раз и играет роль "песочницы", в которую утилиту "пустили поиграть", позволяя вытворять что угодно. Часто бывает, что в "песочнице" есть и свой каталог etc , содержащий необходимые для запуска утилиты (или системной службы) настройки. Вот этот-то etc из "песочницы" также входит в список каталогов, хранящих профиль системы.
В /etc могут находиться не только файлы, но и подкаталоги (особенно в стиле " .d ") и целые поддеревья каталогов. Например, в некоторых дистрибутивах Linux используется подкаталог /etc/sysconfig . Этот каталог создается и заполняется файлами при установке системы или при запуске специального "конфигуратора" – программы-кудесника, задающей наводящие вопросы. Некоторые стартовые сценарии , использующие полученные настройки, также лежат в этом каталоге или его подкаталогах. Если в системе есть каталог /etc/sysconfig , там должны оказаться настройки, относящиеся не к самим службам или утилитам, а к способу их запуска при загрузке, а также языковые и сетевые настройки, тип мыши и т. д.
Подсистема учетных записей
Несколько конфигурационных файлов и способы работы с ними заслуживают отдельного рассмотрения. В первую очередь Мефодий заинтересовался системой учетных записей, о которой упоминалось сразу в нескольких предыдущих лекциях. Итак, существует два файла, доступных для чтения всем пользователям: /etc/passwd , хранящий учетные данные пользователей, и /etc/group , определяющий членство пользователей в группах (во всех, кроме группы по умолчанию):
Оба файла состоят из строк, поля которых разделяются двоеточиями. В файле passwd – семь полей. Первое из них определяет входное имя пользователя – то самое, что вводится в ответ на " login :". Второе поле в ранних версиях UNIX использовалось для хранения ключа пароля . В Linux пользовательские пароли не хранятся нигде – ни в явном виде, ни в зашифрованном. Вместо этого хранится ключ (hash) пароля – комбинация символов, однозначно соответствующая паролю, из которой, однако, сам пароль получить нельзя. Иными словами, существует алгоритм превращения пароля в ключ , а алгоритма превращения ключа в пароль нет. Когда пользователь регистрируется в системе, из введенного им пароля изготавливается еще один ключ . Если он совпадает с тем, что хранится в учетной записи, значит, пароль правильный.
Авторы UNIX предполагали, что, раз пароль из ключа получить нельзя, ключ можно выставлять на всеобщее обозрение, однако выяснилось, что, узнав ключ , пароль можно попросту подобрать на очень мощной машине или в предположении, что пароль – это английское слово, год рождения, имя любимой кошки и т. п. Если подбор пароля сопровождается неудачными попытками входа в систему, это отражается в системных журналах и может быть легко замечено. А завладев ключом , злоумышленник сможет заняться подбором пароля втихомолку на каком-нибудь суперкомпьютере. В конце концов, ключ не нужен никому, кроме подсистемы идентификации , поэтому его вместе с другими полями учетной записи, о которых всем знать не обязательно, из /etc/passwd перенесли в "теневой" файл учетных записей – /etc/shadow . На месте ключа в Linux должна быть буква " x "; если там стоит что-то другое, идентификация пользователя не сработает, и он не сможет войти в систему.
Третье и четвертое поля passwd – идентификатор пользователя и идентификатор группы по умолчанию . Как уже говорилось в лекции 6, именно идентификатор пользователя , а не его входное имя , однозначно определяет пользователя в системе и его права. Можно создать несколько учетных записей с одинаковыми UID, которые различаются другими полями. Тогда при регистрации в системе под именами из этих записей пользователи могут получать разные домашние каталоги и командные оболочки, разное членство в группах, но иметь один и тот же UID. Пятое поле отводится под "полное имя" пользователя; это единственное поле passwd , содержимое которого ни на что не влияет. Наконец, шестое и седьмое поля содержат домашний каталог и стартовый командный интерпретатор пользователя. Если седьмое поле пусто, подразумевается /bin/sh , а если его содержимое не встречается в файле /etc/shells , содержащем допустимые командные интерпретаторы, неизбежны трудности при идентификации пользователя.
Строки файла /etc/group состоят из четырех полей, причем второе – ключ группового пароля – обычно не используется. Первое поле – это имя группы, третье – это идентификатор группы , а четвертое – это список входных имен пользователей, которые в эту группу входят (более точно – для которых эта группа является дополнительной, так как группа по умолчанию указывается в /etc/passwd , хотя никто не мешает продублировать группу по умолчанию и в /etc/group ). Таким образом, определение членства пользователя в группах зависит не от его UID, а от входного имени .
Упомянутый выше файл /etc/shadow , доступ к которому имеет только суперпользователь, также состоит из полей, разделяемых двоеточиями. Помимо входного имени и ключа пароля там указываются различные временные характеристики учетной записи: нижняя и верхняя граница времени жизни пароля, самой учетной записи, дата последнего изменения и т. п. Ключ пароля (второе поле) указывается в одном из поддерживаемых форматов, а если формат не опознан, вся учетная запись считается недействительной. Поэтому один из способов запретить регистрацию пользователя в системе – добавить один символ (например, " !") прямо в поле ключа , отчего все поле становится синтаксически неправильным. Вновь разрешить пользователю входить в систему можно, удалив из поля лишний символ. Именно так работает (с ключами " -L ", lock, и " -U ", unlock) утилита usermod , изменяющая учетную запись. С помощью этой утилиты можно отредактировать и все остальные поля как passwd , так и shadow .
Добавить и удалить пользователя или группу можно с помощью утилит useradd , userdel , groupadd и groupdel соответственно. Не стоит пользоваться текстовым редактором, так как он не гарантирует атомарности операции добавления/удаления, хотя бы потому, что изменению подлежат сразу два файла – passwd и shadow . Даже если необходимо отредактировать /etc/passwd или /etc/group (например, для добавления пользователя в группу или удаления его оттуда), стоит запускать не просто редактор, а vipw или vigr (именно их поведение, позволяющее соблюсти атомарность , копирует утилита visudo , описанная ранее):
Здесь был добавлен пользователь incognito , группа по умолчанию – users, член групп proc и cdrom , полное имя – "Incognito". Стоит заметить, что пароль для этой учетной записи установлен не был (чтобы создать пароль, стоило запустить команду passwd incognito ), и, даже если бы пользователя тут же не удалили ( userdel -r удаляет также и домашний каталог , и почтовый ящик), зарегистрироваться в системе под именем incognito было бы все равно невозможно.
3.2. Конфигурационные файлы, соответствующие стандарту XDG
По стандарту XDG все файлы пользовательской конфигурации хранятся в папке $XDG_CONFIG_HOME (обычно в /home/(username)/.config ).
Внутри $XDG_CONFIG_HOME каждое приложение создаёт свои подпапки для конфигурационных файлов.
Базовой спецификации каталогов XDG теперь придерживаются редактор NeoVim и многие активно развивающиеся приложения. Для пользователей стандарт тоже удобен: одной резервной копии папки $XDG_CONFIG_HOME достаточно, чтобы сохранить все настройки.
2.1. /etc/
Большинство глобальных файлов конфигурации хранится в папке /etc .
Папка /etc/ больше походит на файловую систему с множеством подпапок, в которых размещены соответствующие конфигурационные файлы.
Ниже приведён список наиболее полезных подпапок:
2.2. /etc/opt/
Папка /etc/opt/ должна содержать глобальные файлы конфигурации приложений, установленных в /opt/ . Однако в Linux это требование не является обязательным. В результате бывает, что папка /opt/ полна установленных пользователем программ, а /etc/opt/ остаётся пустой.
Поиск решения задачи
Я решил, что лучший способ защитить мой пароль в Mutt — ввести пароль с клавиатуры, сохранить его в зашифрованном файле GPG, написать на Python скрипт расшифровки для моего GPG-пароля, ну и заодно обеспечить передачу пароля Mutt в скрипт offlineimap, который я использую для локальной синхронизации моего ноутбука с почтовым сервером.
Из подзаголовка статьи ясно, что я буду использовать модули python-gnupg и getpass. Модуль Python python-gnupg — это обёртка для инструмента шифрования gpg. Учтите, python-gnupg не следует путать с модулем под названием gnupg. GnuPG (GPG) — это утилита шифрования для Linux, и я использую её с 2009 года или около того. С ней я чувствую себя комфортно и верю в её безопасность.
Получить пользовательский ввод с помощью Python довольно просто. Вы вызываете input, и всё, что введёт пользователь сохраняется в переменной:
И в этом случае есть одна громадная проблема: когда я ввожу пароль в терминале, всё, что я набираю, видно всем, кто смотрит через моё плечо или просматривает историю моего терминала:
3. Пользовательская конфигурация
Файлы пользовательской конфигурации определяют поведение системы только для задающего настройки пользователя .
Эти файлы, как правило, расположены в домашней папке пользователя и не требуют прав суперпользователя для редактирования.
Следует иметь в виду, что пользовательские настройки всегда имеют более высокий приоритет, чем глобальные. Иными словами, приложение всегда будет придерживаться пользовательских настроек, если таковые есть .
В части пользовательских настроек приложения соответствуют одному из двух стандартов.
3.1. Традиционные файлы конфигурации
Как правило, если у приложения всего один файл конфигурации, его можно найти так: /home/(username)/.(app_name) . Но если конфигурационных файлов больше, то они хранятся в папке /home/(username)/.(app_name) .
Наглядный пример такого приложения — редактор vim .
Запускаем созданный ранее скрипт:
Безопасность даёт свободу
Иногда кажется, что у меня паранойя: я много думаю о тонкостях обеспечения безопасности на моём личном компьютере. Действительно ли SSH конфиг должен иметь разрешения chmod 600? Действительно ли имеет значение, что пароль электронной почты находится в конфигурационном файле, спрятанном в скрытой папке, которая называется, как ни странно, .mutt? Хотя написать подобный скрипт на Python можно и для других конфигурационных файлов.
Зная, что в моих файлах конфигурации отсутствуют незашифрованные конфиденциальные данные, мне намного проще публиковать файлы в общедоступных репозиториях Git, копировать и вставлять сниппеты на форумах и делиться своими знаниями в форме актуальных, рабочих файлов конфигурации. С этой точки зрения, повышение уровня безопасности облегчило мне жизнь. А с таким количеством Python-модулей на все случаи жизни, сделать это было достаточно легко.
Аренда облачного сервера с быстрыми NVMе-дисками и посуточной оплатой у хостинга Маклауд.
Мощность ОС Linux кроется в возможности гибко настраивать систему под наши потребности. Большинство дистрибутивов содержат продвинутые пользовательские интерфейсы для конфигурации системы, однако, по сути, они лишь редактируют текстовые файлы в различных системных папках. Понимая, как работают конфигурационные файлы, мы можем отказаться от этих интерфейсов и повысить свой уровень владения Linux.
Из этого руководства вы узнаете, где файлы конфигурации расположены и каковы их функции. Благодаря стандарту иерархии файловой системы (Filesystem Hierarchy Standard) папки и файлы, которые мы рассмотрим, сохраняют своё расположение даже в разных дистрибутивах.
Прим. переводчика:
Прежде чем двигаться дальше, следует разобраться, как устроена файловая система согласно стандарту FHS.
Все файлы и каталоги располагаются в корневой директории «/» . Даже если эти данные находятся на различных носителях, какие-то из этих каталогов присутствуют, а какие-то могут отсутствовать. В качестве примера можно привести каталоги, связанные с подсистемой X Window, когда каталогов может и не быть, если графическая подсистема не установлена. Однако, большинство каталогов присутствует на всех UNIX-подобных операционных системах и используется аналогичным образом.
Раздел | Корневая директория, содержащая всю файловую иерархию |
---|---|
/bin/ | Утилиты, которые доступны всем пользователям, такие как cat, ls, cp и др. |
/boot/ | Загрузочные файлы (файлы загрузчика, ядро, initrd, System.map). Как правило, выносится на отдельный раздел. |
/dev/ | Файлы устройств. Файлы в данном каталоге обычно создаются драйверами (например, /dev/null, /dev/zero, /dev/sda1). |
/etc/ | Основной каталог конфигурационных файлов системы. |
/home/ | Домашние директории с пользовательскими данными. Могут быть на отдельном разделе либо монтироваться по nfs. |
/lib/ | Основные библиотеки, необходимые для работы программ из /bin/ и /sbin/. |
/media/ | Точки монтирования для сменных носителей, таких как CD-ROM, DVD-ROM, флеш-карты. |
/mnt/ | Используется для монтирования временных файловых систем. |
/opt/ | Дополнительное программное обеспечение. Сюда обычно устанавливаются различные компиляторы и пользовательское ПО, которое не требует соответствия FSHS |
/proc/ | Виртуальная файловая система, представляющая состояние ядра операционной системы и запущенных процессов в виде файлов. |
/root/ | Домашняя директория пользователя root. |
/sbin/ | Основные системные программы для администрирования и настройки системы (например, init, iptables, ifconfig). |
/srv/ | Данные, специфичные для окружения системы. |
/tmp/ | Временные файлы. |
/usr / | Вторичная иерархия для данных пользователя, содержит большинство пользовательских приложений и утилит. |
/usr/bin/ | Дополнительные программы для всех пользователей, не являющиеся необходимыми в однопользовательском режиме. При различных решениях может монтироваться отдельно. |
/usr/include/ | Стандартные заголовочные файлы. |
/usr/lib/ | Библиотеки для программ, находящихся в /usr/bin/ и /usr/sbin/. |
/usr/sbin/ | Дополнительные системные программы (такие как демоны различных сетевых сервисов). |
/usr/share/ | Архитектурно-независимые общие данные. |
/usr/src/ | Исходные коды ядра. |
/usr/local/ | Третичная иерархия для данных, специфичных для данного хоста. Обычно содержит такие поддиректории, как bin/, lib/, share/. |
/var/ | Изменяемые файлы, такие как файлы регистрации (log-файлы), временные почтовые файлы, файлы спулеров. |
/var/lock/ | Лок-файлы, указывающие на занятость некоторого ресурса. |
/var/log/ | Различные log-файлы. |
/var/mail/ | Почтовые ящики пользователей. |
/var/run/ | Информация о запущенных программах (в основном о демонах). |
/var/spool/ | Задачи, ожидающие обработки (например, очереди печати, непрочитанные или неотправленные письма). |
/var/tmp/ | Временные файлы, которые должны быть сохранены между перезагрузками. |
Более детально можно почитать, например,тут.
Написание скрипта с python-gnupg и getpass
Как это часто бывает, ничего самому писать не надо, потому что уже существует модуль Python, который позволяет решить проблему. Это модуль getpass4. С точки зрения пользователя он ведёт себя точно так же, как любое стандартное приглашение к вводу, за исключением того, что не отображает введённые символы.
Установим оба модуля с помощью pip:
2.4. Важные глобальные файлы конфигурации
Вот несколько наиболее полезных глобальных файлов конфигурации:
3.3. Важные файлы пользовательской конфигурации
Среди наиболее часто используемых файлов пользовательской конфигурации следует перечислить:
- $HOME/.xinitrc — в нём содержатся указания о запуске менеджера окон при работе с командой startx;
- $HOME/.vimrc — конфигурация vim;
- $HOME/.bashrc — скрипт, который выполняет командная оболочка bash , когда пользователь запускает командную оболочку без регистрации;
- $XDG_CONFIG_HOME/nvim/init.vim — конфигурация редактора neovim;
- $HOME/.editor — задаёт редактор по умолчанию для данного пользователя;
- $HOME/.gitconfig — в файле указывается имя по умолчанию и адрес электронной почты для указания в коммитах Git;
- $HOME/.profile — командная оболочка с регистрацией выполняет команды из скрипта .profile при запуске;
- $HOME/.ssh/config — конфигурация ssh для конкретного пользователя.
Тестирование скрипта с gpg
Надеюсь, у вас уже установлен gpg, так как сейчас мы будем создавать зашифрованный файл пароля и тестировать скрипт.
Интеграция с offlineimap
Я выбрал Python, потому что знал, что offlineimap может вызывать скрипты, написанные на Python. Если вы уже пользуетесь offlineimap, вы поймете, что единственная необходимая «интеграция» сводится к изменению двух строк в вашем файле .offlineimaprc (точнее — к добавлению одной строки и изменению другой).
Сначала добавьте строку, ссылающуюся на файл нашего скрипта:
Теперь вместо пароля в строке с remotepasseval после знака «=» вызовите функцию get_api_pass(), которая живёт в скрипте password_prompt.py:
Всё! Теперь никто не сможет прочитать пароль из вашего конфигурационного файла!
2. Глобальные файлы конфигурации
Глобальные файлы конфигурации определяют поведение системы в целом .
Как правило, они располагаются в корневом разделе диска ( / ), а доступ к ним требует прав суперпользователя.
Справедливости ради, стоит заметить, что согласно стандарту FHS конфигурационные файлы не хранятся в корневой директории, она пустая и содержит в себе только папки.
Читайте также: