Комментарии 9
Мне кажется, тут просто обязательно надо упомянуть pass (https://www.passwordstore.org/)
Спасибо
Спасибо. Кейс с просмотром пароля, переданного через аргумент запуска, при помощи чтения /proc удивил. Взял на вооружение, что так делать нельзя.
Совет про переменную окружения удивил. Секрет пропадает из /proc/PID/cmdline, но появляется в /proc/PID/environ, и чего мы этим добились?
По трюку с перезапуском и изменением cmdline -- мы на мгновение всё-таки засветим секрет в списке процессов, а это обычно нежелательно, атакующему может повести. Ну и когда на файл с паролем вы делаете chmod 600, это обычно означает, что файл уже полежал с неправильными правами, и пароль лучше сменить. Вместо chmod я бы советовал umask на процессе, или каталог с правами 0700 (chmod на пустой файл до добавления туда пароля — нерабочий вариант, атакующий мог бы открыть этот файл заранее и прочитать после chmod'а)
Если коротко, я с Вами не согласен.
Вам разрешено читать environ файлы другого пользователя, только если у вас есть привелегия CAP_SYS_PTRACE. У обычных пользователей ее нет.
Про создание файла - по тексту 'Файл необходимо разместить в доступной только нужному пользователю папке', что исключает компрометацию.
Трюк с перезапуском - по тексту 'При запуске такой программы пароль будет виден другим пользователям очень недолго', вы или принимаете этот риск, или не принимаете.
Извините за дизлайк, но какой-то трольный коммент у Вас.
Да, свою ошибку с cmdline уже осознал.
По поводу риска временных засветов остаюсь при своём мнении.
Вам разрешено читать environ файлы другого пользователя, только если у вас есть привелегия CAP_SYS_PTRACE. У обычных пользователей ее нет.
Если только не произошла эскалация привилегий, например в ходе lotl атаки
Как правильно передавать секреты запускаемым программам?