Почему в конфигурационных файлах пароли не хранятся в явном виде
Обновлено: 02.07.2024
В моей системе Linux есть файл, который называется «.fetchmailrc», и он используется для настройки адреса электронной почты, с которого fetchmail будет получать почту. Следовательно, я должен ввести свой пароль и адрес электронной почты в виде обычного текста.
Вот как выглядит файл .fetchmailrc:
Я считаю, что должен быть лучший способ сделать это, поскольку, если хакер получит доступ к моему серверу, он сможет легко прочитать файл и получить мои учетные данные.
Я слышал, что в системах Linux есть PAM (Pluggable Authentication Modules), но я не знаю, связано ли это с тем, что я пытаюсь сделать.
2 ответа 2
Независимо от того, как вы храните свои пароли, при запуске программы, которая не запрашивает ваши пароли, программа должна расшифровать сохраненный пароль с помощью информации, доступной на сервере. "Хакер", получивший доступ к вашему серверу, может использовать всю информацию, хранящуюся на сервере. Таким образом, он также может расшифровать пароль так же, как программа расшифровывает его.
Если схема, которую вы используете для шифрования и хранения вашего пароля, немного сложнее, "хакеру" может потребоваться немного больше времени.
Поэтому нет способа сделать то, что вы хотите: независимо от того, как вы храните свой пароль, вы не можете сделать его "безопасным для хакеров". Хакер просто должен делать то, что делает программа (или, может быть, даже просто запустить программу и перехватить сетевой трафик).
Модули PAM не имеют к этому никакого отношения. Они не предназначены для хранения паролей, но предоставляют способы настройки методов проверки подлинности для существующих служб Linux. Для этого должна быть написана программа, желающая использовать PAM.
Если вы беспокоитесь о том, что кто-то получит повторный root-доступ к вашей системе, то после этого вы практически ничего не сможете сделать. (Но это кошмар, следуйте рекомендациям и сохраняйте хорошие резервные копии).
Однако, если все по-прежнему безопасно, тогда вы могли бы сделать намного лучше, чем оставить пароль в текстовом файле (любой, кто найдет ваш работающий или выключенный системный диск, сможет его прочитать). Делать такие вещи, как:
Как вывести свою систему на новый уровень безопасности с модулями python-gnupg и getpass4.
Изображение : freeGraphicToday, via Pixabay. CC0.
В условиях растущих требований к безопасности создание и хранение паролей может вызвать вопросы не только для пользователей, но и у разработчиков и системных администраторов. Специалисты и другие осведомлённые люди знают, что пароли нужно хранить в зашифрованном виде. Уже на этапе ввода символы пароля нужно скрывать от любых глаз (даже от того человека, который его вводит). Всегда ли мы можем выполнить хотя бы эти требования?
Я единственный пользователь своего ноутбука, а на его борту крутится ОС семейства Linux. Поэтому меня не беспокоят пользователи, которые могут случайно или неслучайно посмотреть мои конфигурационные файлы, работая на этом же компьютере. Я решил заморочиться и повысить безопасность своего личного ноутбука, и на то есть свои причины. Да, я шифрую свой домашний каталог, но как только вхожу в систему, любой пароль, хранящийся в виде простого текста в файле конфигурации, потенциально может быть уязвим для чересчур любопытных глаз.
К тому же, я использую почтовый клиент Mutt. Он позволяет мне читать и составлять электронные письма прямо в Linux-терминале. Мне удобно, мне нравится. Правда, ему нужно, чтобы я хранил пароль в файле конфигурации (.mutt), либо всё время вводил пароль в интерактивном режиме. Поэтому я ограничил права доступа к моему конфигурационному файлу Mutt, чтобы его мог видеть только я.
Но есть ещё один важный момент: я периодически пишу технические статьи, составляю туториалы, помогаю людям в сообществе и публикую много своего кода в общедоступных репозиториях, публикую скриншоты своего экрана, часто показываю что-то на примере своей рабочей системы. Если по недосмотру меня угораздит засветить в Интернете (или где-то ещё) данные (и в том числе пароли) из моих конфигурационных файлов, это бросит неприятную тень на мою репутацию и безопасность. Так что надо подстраховаться.
Ну и, если вдруг злоумышленник завладеет моим ноутбуком или каким-то другим образом получит доступ в систему, он не сможет получить мой пароль без боя, просто запустив cat для просмотра логов и конфигов.
Поиск решения задачи
Я решил, что лучший способ защитить мой пароль в Mutt — ввести пароль с клавиатуры, сохранить его в зашифрованном файле GPG, написать на Python скрипт расшифровки для моего GPG-пароля, ну и заодно обеспечить передачу пароля Mutt в скрипт offlineimap, который я использую для локальной синхронизации моего ноутбука с почтовым сервером.
Из подзаголовка статьи ясно, что я буду использовать модули python-gnupg и getpass. Модуль Python python-gnupg — это обёртка для инструмента шифрования gpg. Учтите, python-gnupg не следует путать с модулем под названием gnupg. GnuPG (GPG) — это утилита шифрования для Linux, и я использую её с 2009 года или около того. С ней я чувствую себя комфортно и верю в её безопасность.
Получить пользовательский ввод с помощью Python довольно просто. Вы вызываете input, и всё, что введёт пользователь сохраняется в переменной:
И в этом случае есть одна громадная проблема: когда я ввожу пароль в терминале, всё, что я набираю, видно всем, кто смотрит через моё плечо или просматривает историю моего терминала:
Написание скрипта с python-gnupg и getpass
Как это часто бывает, ничего самому писать не надо, потому что уже существует модуль Python, который позволяет решить проблему. Это модуль getpass4. С точки зрения пользователя он ведёт себя точно так же, как любое стандартное приглашение к вводу, за исключением того, что не отображает введённые символы.
Установим оба модуля с помощью pip:
У меня получился вот такой скрипт для создания пароля с невидимым вводом и расшифровкой:
Сохраните файл как password_prompt.py, если хотите попробовать скрипт у себя. Если вместе с ним вы хотите использовать offlineimap, укажите в конфигурационном файле .offlineimaprc имя и путь к скрипту с паролем (у меня это
/.mutt/password_prompt.py). Правда, там нужно сделать ещё кое-что, но об этом позже.
Тестирование скрипта с gpg
Надеюсь, у вас уже установлен gpg, так как сейчас мы будем создавать зашифрованный файл пароля и тестировать скрипт.
Запускаем созданный ранее скрипт:
/.mutt/pass.gpg. Значит, скрипт работает правильно.
Интеграция с offlineimap
Я выбрал Python, потому что знал, что offlineimap может вызывать скрипты, написанные на Python. Если вы уже пользуетесь offlineimap, вы поймете, что единственная необходимая «интеграция» сводится к изменению двух строк в вашем файле .offlineimaprc (точнее — к добавлению одной строки и изменению другой).
Сначала добавьте строку, ссылающуюся на файл нашего скрипта:
Теперь вместо пароля в строке с remotepasseval после знака «=» вызовите функцию get_api_pass(), которая живёт в скрипте password_prompt.py:
Всё! Теперь никто не сможет прочитать пароль из вашего конфигурационного файла!
Безопасность даёт свободу
Иногда кажется, что у меня паранойя: я много думаю о тонкостях обеспечения безопасности на моём личном компьютере. Действительно ли SSH конфиг должен иметь разрешения chmod 600? Действительно ли имеет значение, что пароль электронной почты находится в конфигурационном файле, спрятанном в скрытой папке, которая называется, как ни странно, .mutt? Хотя написать подобный скрипт на Python можно и для других конфигурационных файлов.
Зная, что в моих файлах конфигурации отсутствуют незашифрованные конфиденциальные данные, мне намного проще публиковать файлы в общедоступных репозиториях Git, копировать и вставлять сниппеты на форумах и делиться своими знаниями в форме актуальных, рабочих файлов конфигурации. С этой точки зрения, повышение уровня безопасности облегчило мне жизнь. А с таким количеством Python-модулей на все случаи жизни, сделать это было достаточно легко.
Аренда облачного сервера с быстрыми NVMе-дисками и посуточной оплатой у хостинга Маклауд.
Несколько конфигурационных файлов и способы работы с ними заслуживают отдельного рассмотрения. В первую очередь Мефодий заинтересовался системой учётных записей, о которой упоминалось сразу в нескольких предыдущих лекциях. Итак, существует два файла, доступных для чтения всем пользователям: /etc/passwd , хранящий учётные данные пользователей, и /etc/group , определяющий членство пользователей в группах (во всех, кроме группы по умолчанию):
$ cat /etc/passwd
root:x:0:0:System Administrator:/root:/bin/bash
bin:x:1:1:bin:/:/dev/null
daemon:x:2:2:daemon:/:/dev/null
adm:x:3:4:adm:/var/adm:/dev/null
lp:x:4:7:lp:/var/spool/lpd:/dev/null
. . .
nobody:x:99:99:Nobody:/var/nobody:/dev/null
shogun:x:400:400:Лев Гуревич:/home/shogun:/bin/zsh
methody:x:503:503:Мефодий Кашин:/home/methody:/bin/bash
methody@localhost:
$ cat /etc/group
root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin,adm
adm:x:4:root,adm,daemon,shogun
wheel:x:10:root,shogun
. . .
proc:x:19:root,shogun
shogun:x:400:
methody:x:503:
Пример 6. Файлы /etc/passwd и /etc/group
Оба файла состоят из строк, поля которых разделяются двоеточиями. В файле passwd — семь полей. Первое из них определяет входное имя пользователя — то самое, что вводится в ответ на « login: ». Второе поле раньше, в ранних версиях UNIX, использовалось для хранения ключа пароля. В Linux пользовательские пароли не хранятся нигде, ни в явном виде, ни в зашифрованном. Вместо этого хранится ключ (hash) пароля — комбинация символов, однозначно соответствующая паролю, из которой, однако, сам пароль получить нельзя. Иными словами, существует алгоритм превращения пароля в ключ, а алгоритма превращения ключа в пароль нет. Когда пользователь регистрируется в системе, из введённого им пароля изготавливается ещё один ключ. Если он совпадает с тем, что хранится в учётной записи, значит, пароль правильный.
Авторы UNIX предполагали, что, раз пароль из ключа получить нельзя, ключ можно выставлять на всеобщее обозрение, однако выяснилось, что, узнав ключ, пароль можно попросту подобрать на очень мощной машине или в предположении, что пароль — это английское слово, год рождения, имя любимой кошки и т. п. Если подбор пароля сопровождается неудачными попытками входа в систему, это отражается в системных журналах и может быть легко замечено. А завладев ключом, злоумышленник сможет заняться подбором втихомолку на каком-нибудь суперкомпьютре. В конце концов, ключ не нужен никому, кроме подсистемы идентификации, поэтому его, вместе с другими полями учётной заиси, о которых знать всем не обязательно, из /etc/passwd перенесли в «теневой» файл учётных записей /etc/shadow . На месте ключа в Linux должна быть буква « x »; если там стоит что-то другое, идентификация пользователя не сработает, и он не сможет войти в систему.
Третье и четвёртое поля passwd — идентификатор пользователя и идентификатор группы по умолчанию. Как уже говорилось в лекции Права доступа именно идентификатор пользователя, а не его входное имя, однозначно определяет пользователя в системе и его права. Вполне возможно создать несколько учётных записей с одинаковыми 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 было бы всё равно невозможно.
Подсистема идентификации
Подсистемой учётных записей пользуется подсистема идентификации, которая в Linux имеет модульную структуру и называется PAM (Pluggable Authentication Modules, т. е. Подключаемые Модули Идентификации). Идея PAM — в том, чтобы унифицировать и, вместе с тем, сделать более гибкой любые процедуры идентификации в системе — начиная от команды login и заканчивая доступом к файлам по протоколу, скажем, FTP. Для этого недостаточно просто написать «библиотеку идентификации» и заставить все программы её использовать. В зависимости от того, для чего производится идентификация, условия, при которых оня будет успешной, могут быть более или менее строгими, а если она прошла успешно, бывает нужно выполнить действия, связанные не с определением пользователя, а с настройкой системы.
В большинстве дистрибутивов PAM обучен схеме «. d», и настройки каждой службы, которая использует идентификацию, лежат в отдельном файле:
В PAM определено четыре случая, требующие идентифкации: auth — собственно идентификация, определние, тот ли пользователь, за кого он себя выдаёт, account — определение, всё ли хорошо с учётной записью пользователя, password — изменение пароля в учётной записи, и session — дополнительные действия непосредственно перед или непосредственно после того, как пользователь получит доступ к затребованной услуге. Эти значения принимает первое поле любого файла настройки из pam.d , а в третьем поле записывается модуль, который проверяет какой-нибудь из аспектов идентификации. Второе поле определяет, как успех или неуспех проверки одного модуля влияет на общий успех или неуспех идентификации данного типа (например, required означает, что в случае неуспеха модуля проверка пройдена не будет). Четвёртое и последующие поля отведены под параметры модуля.
Такие настройки login обнаружил Мефодий на своём компьютере. Во всех четырёх случаях используется включаемый файл system-auth (к нему обращаются и другие службы), с некоторыми дополнениями: во время идентификации pam_nologin.so дополнительно проверяет, не запрещено ли пользователям регистрироваться вообще (как это бывает за несколько минут до перезагрузки системы), а перед входом в систему и после выхода из неё pam_console.so выполняет описанную в лекции Права доступа «передачу прав на владение устройствами» (и, соответственно, лишение пользователя этих прав).
Каталог /etc/pam.d — замечательный пример того, как профиль определяет поведение системы. В частности, четыре первых строки из system-auth показывают, что в этом дистрибутиве используется не просто «теневой» файл паролей, а схема TCB, описанная в лекции Права доступа. (Как уже известно Мефодию, в этой схеме вместо общего для всех /etc/shadow задействованы файлы вида /etc/tcb/входное_имя/shadow , причём права доступа к ним устроены таким образом, чтобы при выполнении команды passwd можно было обойтись без подмены пользовательского идентификатора на суперпользовательский).
Подсистема системных журналов
Все события, сообщаемые syslogd , подразделяются горизонтально — по типу службы (facility), с которой это событие произошло события, и вертикально — по степени его важности (priority). Типов событий насчитывается около двадцати (среди них auth , daemon , kern , mail и т. п., а также восемь неименованных, от local0 до local7 ). Степеней важности всего восемь, по возрастанию важности: debug , info , notice , warning , err , crit , alert и emerg . Таким образом, каждое событие определяется парой значений, например, mail.err означает для syslogd событие, связанное с почтой, притом важности не меньшей err . Из таких пар (с возможной заменой типа или важности на « * », что означает «любые», или none , что означает «никакие») составляется конфигурационный файл /etc/syslog.conf :
Выполнение действий по расписанию
Другой пример типичной для Linux службы, управляемой конфигурационным файлом, — демон cron , регулярно выполняющий в заданное время заданные действия.
Программисты имели в виду Хроноса, стихийное божество времени у древних греков. Уже сами греки часто называли так «владыку неба» титана Крона (отца богов-кронидов и, среди прочих, Зевса, который впоследствии папу и других титанов заключил в Тартар, и стал владыкой неба сам). У древних римлян и Крон и Хронос почитались под именем Сатурна, божества неумолимого времени.
Время от времени в системе необходимо обновлять разнообразные файлы, например, базы данных антивирусов (вирусов в Linux нет, а антивирусы есть!), базу данных whatis или список всех доступных на чтение файлов системы, locatedb (поискать по этому списку можно командой locate ); нужно собирать статистику по работе системы, анализировать цельность системы (этим занимаются службы OSec, TripWire или AIDE) и производить множество других регулярных действий. Всем этим и занимается демон cron .
Конфигурационный файл демона cron называется /etc/crontab .
Первые пять полей этого файла определяют время запуска команды: минуту, час, число месяца, месяц и день недели. Символ « * » означает, что соответствующая часть даты не учитывается. Шестое поле — имя пользователя, от лица которого зпускаются команда, указанная в остальных полях строки. Так, в примере команда run-parts /etc/cron.weekly будет запускаться в 4 часа 22 минуты каждое воскресенье (нулевой день) любого числа любого месяца.
Как видно из примера, обычно /etc/crontab невелик: чаще всего он состоит из почасового, подённого, понедельного и помесячного запуска специального сценария (в примере — run-parts ). Этот сценарии реализует упрощённую схему «. d», он попросту запускает отсортированные в лексикографическом порядке сценарии из соответствующего каталога (например, из /etc/cron.daily ):
То есть в таком порядке, в котором они были бы расставлены в словаре. Причём цифры предшествуют алфавитным знакам, а между собой сортируются по возрастанию, от 0 до 9. Отсюда « 000anacron » — такое имя обеспечит, чтобы этот сценарий был выполнен самым первым.
Вот что происходит каждый день на машине Мефодия: запуск anacron и «прокручивание» системных журналов (об этом речь пойдёт далее), обновление базы whatis , проверка цельности системы с помощью osec , прореживание старых и неиспользуемых файлов в /tmp (утилита stmpclean ) и, наконец, обновление базы locatedb .
Пользователям системы можно разрешить иметь собственные расписания, также обрабатываемые демоном cron. Эти расписания имеют тот же синтаксис, что и crontab , только шестое поле («user») в них отсутствует. Редактировать пользовательские таблицы рекомендуется с помощью команды crontab -e (чтобы не подсунуть демону синтаксически неверный файл). Сами таблицы могут храниться, в зависимости от версии и настроек cron , в /var/spool/cron/crontabs , /var/spool/cron , /var/cron/tabs или ещё где-нибудь.
Служба anacron появилась в Linux-системах в то время, когда их начали активно использовать на пресональных рабочих станциях. Такие станции, в отличие от серверов, не обязаны работать круглосуточно. Скорее всего, на ночь, на праздники и на время отпуска их выключают. Это значит, что все настройки cron надо менять в соответствии с графиком включений/выключений (иначе cron.daily никогда не выполнится в четыре часа ночи) — или запускать отдельную службу, которая будет выполнять некоторые задачи не по расписанию, а потому что их давно уже пора запустить.
Название этого демона пародирует cron с намёком на анахронизм, то есть несвоевременность выполнения заданий.
Дополнительно anacron рассчитывает запуск задач так, чтобы не перегрузить компьютер работой, если их накопилось слишком много. Конфигурационный файл anacron называется /etc/anacrontab .
«Прокручивание» системных журналов
Ещё изучая работу syslog , Мефодий не расставался с мыслью, что файл, в котором записывается системный журнал, постоянно растёт. Это значит, что каков бы ни был размер файловой системы /var , она в конце концов заполнится журналами под завязку — если как-то их не укорачиваить. К сожалению, в Linux укоротить файл от начала, отрезав самые старые записи, нельзя, как нельзя и добавлять новые записи в начало файла. Эти операции легко реализовать с помощью копирования нужной области в новый файл и последующего переименования, но, во-первых, соблюсти атомарность таких составных операций нелегко, а во-вторых, они требуют удвоенного места в файловой системе на время работы (и, стало быть, каких-то аварийных процедур на случай нехватки места).
Поэтому в Linux принят другой, существенно менее ресурсоёмкий алгоритм, позволяющий избежать переполнения /var : т. н. «прокручивание» системных журналов. Суть алгоритма в следующем: когда настаёт пора укоротить журнал (например, раз в неделю или если файл журнала достиг определённого размера), этот файл переименовывают, и открывают новый пустой файл с тем же именем. Если хранить несколько (скажем, семь) переименованных старых файлов, с ними уже можно произвоить операцию «отбрасывния старого»: самый старый — седьмой — файл удаляется, шестой переименовывается в седьмой, пятый — в шестой, и т. д. до первого (моложе которого только текущий журнал), который переименовывается во второй. Только тогда можно переименовать текущий журнал в «первый старый», и открыть новый. Получается очередь устаревающих файлов, пополняемая с одной стороны и усекаемая с другой.
Как правило имя «первого старого» журнала получается добавлением к имени журнала суффикса « .1 », второго — « .2 » и т. д.:
Навеяно обнаруженной недавно критической уязвимостью в одном из фреймворков, который, правда, ещё не релизнулся: Был доступен просмотр любых файлов проекта, в том числе, конфигурационного файла. А в нём - ключ, которым подписывается сессия (и по умолчанию хранится только в Cookie), а так же некоторые хранят там данные для подключения к БД. В связи с этим вопрос, где таки хранить данные для подключения к БД и др. подобные вещи? В переменных среды? Или таки нужно вместо паролей использовать ещё что?
man криптография // thread
не в открытом доступе, ели есть физический доступ к файлам программы, то уже можно не рыпаться
а субд должно торчать только в локалхост
Так-с. В чём профит криптографии для хранения данных подключения к БД в случае, когда все файлы проекта оказались доступны публично?
Слушай, либо ты читаешь хотя бы историю и понимаешь зачем и почему что-то придумали. Либо не занимаешься этими вопросами вообще. Даже не подходи к компьютерам.
Коротко ответ на твой вопрос:
В связи с этим вопрос, где таки хранить пароли? В переменных среды? Или таки нужно вместо паролей использовать ещё что?
Где угодно. Важно зашифровать пароли стойким алгоритмом. Если на взлом шифра требуется несколько лет этого уже более чем достаточно в 95% случаях.
Последнее исправление: gh0stwizard 22.02.14 15:49:17 (всего исправлений: 1)
а субд должно торчать только в локалхост
Согласен, что в случае, если наш web сервис и БД находятся на одном физическом сервере, то БД в Интернеты смотреть не должна. Но не всегда это так.
Друг мой, ты говоришь не о том. Вот тебе конспект:
Был доступен просмотр . конфигурационного файла. . некоторые хранят там данные для подключения к БД
Поскольку ты изменил вопрос уже после. и теперь это что-то вменяемое, отвечаю.
В связи с этим вопрос, где таки хранить данные для подключения к БД и др. подобные вещи? В переменных среды? Или таки нужно вместо паролей использовать ещё что?
Ответ на этот вопрос хорошо описан у Эрика Рэймонда. По сути все эти пароли security by obscurity. Рассмотрим случай, когда пароль передается через параметры запуска программы: $ ps xawu выдаст нам результат. Любые манипуляции с файлами, до которых есть доступ у текущего процесса дадут результат.
Более сложные схемы:
- Две базы: в одной ключи, в другой данные
- Hardware-based: удаленный ввод пароля/шифра, usb-ключи, сканеры сетчатки глаза и т.п.
И тем не менее, данные из самого процесса можно извлечь. Следовательно все, чем оперирует процесс надо шифровать, а ключ еще раз шифровать. и так до бесконечности.
Для поделий на гитхабе текущая схема проекта идеальна: она проста, удобна, не жрет лишних ресурсов и проверена временем. То, что нашли дыру — критичный баг, который закроют и все будет чики пуки. ИМХО, это напоминает возрождение Joomla, которая несла, несет и будет нести в себе подобные баги, ибо это не лечится :)
Поскольку ты изменил вопрос уже после. и теперь это что-то вменяемое
Это было вменяемым с самого начала (заметь, первый комментатор всё понял правильно). Вопрос был отредактирован для Ъ, читающих только заголовок и последнее предложение.
Ссылка на хорошо описанный ответ точно верна? Ничего подобного не нашёл, кроме нескольких предложений о том, что автор не хотел давать ложного чувства безопасности пользователям, поэтому не предусмотрел возможности шифровать паролей, и заключения в виде:
Система безопасности надежна, пока надежны ее секреты. Избегайте псевдо-секретов.
Любые манипуляции с файлами, до которых есть доступ у текущего процесса дадут результат.
Если есть доступ к выполнению произвольных команд от имени процесса - это конечно уже фейл и с этим ничего не поделаешь. Но в стартовом посте была ссылка на уязвимость, которая позволяла лишь смотреть системные файлы вне public директории (а это только config файл).
Как правило, конфигурационный файл считывается программой при запуске, отражая, таким образом, ее состояние на момент старта. Изменения настроек работающей программы в конфигурационном файле , как правило, не отражаются. Тому есть несколько причин: не стоит превращать файл, изредка редактируемый пользователем, в файл, изменение которого происходит постоянно; не стоит держать конфигурационный файл всегда открытым; тяжело, изменяя файл автоматически, не испортить структуру комментариев (интерпретируемых не машиной, а пользователем) и т. д. Впрочем, многие утилиты, особенно использующие графическую среду, могут записывать настройки в файл по окончании работы. Большинство конфигурационных файлов весьма удобно редактировать вручную, с помощью 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 было бы все равно невозможно.
Читайте также: