Пароль в праметре командной строки xfreerdp - безопасно?

Там тоже звездочки.

Вроде, в линуксе можно программно изменить содержимое cmdline.

Но пароль есть самом скрипте. Скрипт после запуска уничтожается?

Пароль можно подсмотреть в момент времени когда оно только запускается но ещё не успело затереть его.

А вообще если глубоко копать подобные вопросы - обнаружишь что там кругом дыры и страшно. Если у тебя на компе заведётся шпионский софт то этот пароль он в любом случае украсть сможет, даже если ты его другим способом будешь передавать.

Я бы посмотрел ещё в env переменных самого процесса и прошёлся по цепочке родителей. Так же можно погрепать память процесса в поисках пароля

Не, в скрипте пароля нет. Он берется из keepass.

Вот, собственно, скрипт:

#!/bin/sh

SERVER="rdp.udalenka.work.tridevjatoye.ru"
PORT="3389" #на самом деле другой

echo -n 'pass: ' # это пароль для доступа к db keepass
PASS="$(keepassxc-cli show -a password -s /home/$USER/db.kdbx -k /home/$USER/db.key 'RDP ENDTRY NAME' --quiet)"

xfreerdp3 /u:dobry_molodec /p:"$PASS" /d:'' /v:$SERVER:$PORT /t:tridevjatoye /drive:home,/home/$USER /bpp:24 /compression-level:2 -decorations +dynamic-resolution +rfx /rfx-mode:video -themes -wallpaper /cert:ignore +clipboard +f

Я бы посмотрел ещё в env переменных самого процесса

В cat /proc/$PID/environ |tr "\0" "\n" тоже нет…

Так же можно погрепать память процесса в поисках пароля

Память процесса - это уже сложно…

Если тот, кто проникнет, доберется до памяти процесса, от такого уже не спастись, видимо )

В man xfreerdp3 есть параметр --from-stdin

Можно попробовать передат пароль через pipe, тогда пароль не буддет светиться в командной строке

# набросок
xfreerdp3 --user:user --from-stdin <<EOF
$(keepass-cli)
EOF

Чего тут сложного? Если рассматривать возможность выполнения команд или кода на хосте(а иначе чего бояться компрометации пароля в командной строке?), то найти рабочий privilege escalation как будто не проблема. А с рутовыми привилегиями можно смотреть любую память

Проще mitm. Xrdp есть шифрование протокола?

Чего тут сложного? Если рассматривать возможность выполнения команд или кода на хосте(а иначе чего бояться компрометации пароля в командной строке?), то найти рабочий privilege escalation как будто не проблема. А с рутовыми привилегиями можно смотреть любую память

Ну, это уже не вопрос запуска приложения с паролем в параметре cmd, это проблема защиты хоста в целом…

Проще mitm. Xrdp есть шифрование протокола?

Да, есть шифрование. И клиент и сервер поддерживают шифрование.

keepassxc-cli show -a password -s /home/$USER/db.kdbx -k /home/$USER/db.key 'RDP ENDTRY NAME' --quiet

Не, в скрипте пароля нет. Он берется из keepass.

Ну тогда, точно так же как и скрипт, брать из кипасс)

# это пароль для доступа к db keepass

И другие тоже!

Пароль к db keepass вводится интерактивно.

echo -n 'pass: ' - это просто промпт самопальный ) т.к., keepassxc-cli с параметром --quiet не выводит ничего (а без --quiet лишнее выводит).

В man xfreerdp3 есть параметр –from-stdin

Надо будет поэксмериментировать… Что-то не взлетает сходу…

Можно в скриптах операции с паролями обворачивать umask:

( umask 177
    PASS="$(keepassxc-cli show -a password -s /home/$USER/db.kdbx -k /home/$USER/db.key 'RDP ENDTRY NAME' --quiet)"

    xfreerdp3 /u:dobry_molodec /p:"$PASS" /d:'' /v:$SERVER:$PORT /t:tridevjatoye /drive:home,/home/$USER /bpp:24 /compression-level:2 -decorations +dynamic-resolution +rfx /rfx-mode:video -themes -wallpaper /cert:ignore +clipboard +f
)

Так переменная PASS далеко не утечет и все создаваемые файлы будут доступны на чтение и запись только пользователю.

Ну а пароль сам передается в каком виде, он же зашифрованный, подсоленный, а не голый текст?

https://github.com/FreeRDP/FreeRDP/issues/3639 - тут обсуждение. Можешь почитать чё кого. По мне для использования на +- доверительной машине вполне секурно.

В общем, сделал с использованием параметра /from-stdin:

#!/bin/sh

SERVER="rdp.udalenka.work.tridevjatoye.ru"
PORT="3389" #на самом деле другой

echo -n 'pass: ' # подсказка о запросе пароля для базы keepassxc

xfreerdp3 /u:dobry_molodec /d:'' /v:"$SERVER:$PORT" /t:tridevjatoye /drive:home,/home/$USER /bpp:24 /compression-level:2 -decorations +dynamic-resolution +rfx /rfx-mode:video -themes -wallpaper /cert:ignore +clipboard +f /from-stdin <<EOF
$(keepassxc-cli show -a password -s /home/$USER/db.kdbx -k /home/$USER/db.key 'RDP udalenka' --quiet)
EOF

Всем спасибо!

Какая-то безопасность ради безопасности без внятной модели угроз. У 98% твоих коллег по удалёнке пароль сохранён в виндовом RDP-клиенте, и никого это не парит. Судя по тому, что у тебя на клиенте Linux и ты сам там что-то решаешь, endpoint security в конторе даже не пахнет.

У вас там что, RDP прямо через интернет?

С поднятием туннеля подобного вопроса не возникает, я этому моменту не стал уделять внимание здесь…

А вы как решаете у себя этот вопрос для сотрудников на удаленке?

Какой конкретно? У нас не те масштабы, чтобы были вещи типа ES, но RDP через интернет точно не используем :) Если требуется только 1С, то оно умеет работать через нормальный HTTPS, дополнительно есть аутентификация на реверс-прокси (не уверен, что это дофига повышает безопасность, но хотя бы без прохождения этого шага не видно, что там за ним). Для пары привилегированных пользователей — wireguard.

Но мой поинт был в том, что ты заморачиваешься с какими-то паролем, который никому не нужен. Слишком причудливый сценарий атаки, когда ради пароля внедряется вредоносный софт на твой компьютер, и он шарится по /proc/*/cmdline в надежде там найти пароль. Проще уж завести сразу кейоггер и утащить твою базу паролей, но, опять же, на практике это выглядит не очень правдоподобно, если ты не руководитель или другая примечательная цель.

*кейлоггер

У 98% твоих коллег по удалёнке пароль сохранён в виндовом RDP-клиенте

Тётя Ванга? Или вы с ТС знакомы лично?

Первое. Endpoint security (будем честны, зачастую это кривое говно с опасной иллюзией безопасности) придумали не от хорошей жизни и не от большой щедрости. По уму, удалённые работники должны работать на устройствах, полностью подконтрольных работодателю, а не вот так вот, как ТС.

У нас не те масштабы, чтобы были вещи типа ES

Вот и у меня тоже.

Но мой поинт был в том, что ты заморачиваешься с какими-то паролем, который никому не нужен. Слишком причудливый сценарий атаки, когда ради пароля внедряется вредоносный софт на твой компьютер…

Специально, конечно, вряд ли кто-то полезет. А вирусы, черви, которые эксплуатируют какие-нибудь уязвимости для распространения и в автоматическом режиме передают найденное куда-то там - это более вероятно. И, как мне думается, по этой причине можно задумываться и о том, как и где светится пароль, передаваемый в параметрах…

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

Много ты таких видел? На практике это чаще DDoS, криптомайнинг, рассылка спама, вымогательство и прочие практичные вещи. Ну да ладно, я не эксперт в области вредоносного ПО, просто очень давно не слышал про массовые атаки такого типа, как ты описываешь. Это больше похоже на таргетированные, которые проводят точечно и с упором больше на социальную инженерию, нежели технические средства.

Да просто погуглите: «червь под linux ворует данные».

Но на самом деле, это просто мне так хочется и было интересно узнать. Если что-то можно сделать более безопасно - почему бы и нет? )

Кто знает, может быть, такие привычки уже спасали мои аккаунты от всяческих проказников, или спасут в будущем…

Да просто погуглите: «червь под linux ворует данные».

Погуглил, предлагаю и тебе попробовать. Как и следовало ожидать, на первой странице из релевантного примерно одна ссылка с чем-то заточенным под криптокошельки (мне следовало это включить в перечень в своём комментарии). Если немного вникнуть в вопрос, как оно работает, то несложно заметить, что на типичный десктоп в большинстве случаев тебе придётся тащить вирус самостоятельно, он не прилетит откуда-то по волшебству.

Кто знает, может быть, такие привычки уже спасали мои аккаунты от всяческих проказников

У тебя браузерные cookies лежат в открытом виде для этого, но, похоже, их пока никто не трогал. Странно!

Куки, всё-таки, не совсем пароли. Но спорить, конечно, не буду, их кража может тоже привести к не оч. приятным последствиям…

В общем, думаю, не стоит следовать поговорке: «Горит сарай - гори и хата!»

Меньше чувствительных данных доступно - лучше.

Куки, всё-таки, не совсем пароли.

Это даже лучше в некоторых случаях :) Реально пароли вообще мало смысла воровать, особенно когда везде 2FA (а где нет, то там и интересного ничего нет).

Меньше чувствительных данных доступно - лучше.

С этим я совершенно согласен. А засвечивание паролей и прочих таких данных в командной строке нормой никогда особо не было в многопользовательских ОС, если вернуться к изначальному вопросу :) Если не ошибаюсь, командную строку чужих процессов в Linux по умолчанию видно любому пользователю.

Если не ошибаюсь, командную строку чужих процессов в Linux по умолчанию видно любому пользователю.

Не должно. В прочим допускаю в разных дистрах разное.

Опция монтирования hidepid=2 должна быть для /proc включена.

А чтобы процессы одного пользователя к друг другу а память не лазили надо ещё и YAMA включать.

Это даже лучше в некоторых случаях :) Реально пароли вообще мало смысла воровать, особенно когда везде 2FA (а где нет, то там и интересного ничего нет).

Я думаю, тут индивидуально всё.

У меня в Keepass ~200 записей, 2FA штук у пяти-семи включено.

И я не сказал бы, что доступ к вэбке электронной почты, например, или форума какого-то, не будет представлять интерес для мошенника, который будет соц. инженерией заниматься. А тех, кто 2FA на свои почтовые сервисы (и форумы) настраивает не думаю, что так уж много )

Кроме того, там пароли не только от сайтов. RDP, VPN, прочие сервисы и приложения.

В общем, вы не убедили меня, что я зря заморачиваюсь )

Хотя, я особо и не заморачиваюсь. Просто интересны некоторые вопросы )