Сохраняются ли данные в памяти при отключении сети? Если да, то как я могу увидеть эти данные?
Я рекомендую не использовать xinit, так как он уязвим . Вместо этого используйте startx. xinit, кажется, написано, чтобы принимать X-соединения от любого ID пользователя без предупреждения или документации. startx, по-видимому, исправляет это. Я не знаю, почему эту ситуацию терпят и как это вообще произошло.
Как root:
systemd-run --property PAMName=login \
--property User=my-user \
--property StandardInput=tty \
--property TTYPath=/dev/tty8 \
sh -c 'chvt 8 && startx /usr/bin/xterm -- :1'
Магия заключается в определении PAMName=открытия сеанса PAM и связывании этого сеанса с конкретным TTY. Это заставляет pam _systemd делать то, что вы хотите. Я подделал login-, хотя технически вы должны определить новое «имя службы» PAM на случай, если оно потребует особого обращения.
Таким образом, вы можете написать скрипт, который выполняет нужную команду. Затем предоставьте доступ для запуска этого сценария от имени пользователя root, используя sudo.
Если вы используете SELinux,вам придется бороться и с этим.
Я ожидаю, что это будет зависеть от того, что делает M2 и как M3 закрывается. Кроме того, если вы рассматриваете это с точки зрения безопасности, насколько это важно, зависит от того, как вы определяете свою модель угроз и требуемый уровень безопасности.
Если М2 принимает активное участие в обмене данными на уровне TCP , то есть если между М1 и М2 есть TCP-соединение, а между М2 и М3 другое, то ОС на М2 должна будет сохранять любые отправленные данные до тех пор, пока M3 не подтвердит прием (или пока не закончатся различные таймеры, закрывающие соединение с ошибкой ). В этом не было бы необходимости, если бы это было соединение UDP или если бы M2 действовал только как IP-маршрутизатор. Как для IP, так и для UDP пакеты/датаграммы отправляются, а затем забываются, и за это отвечают протоколы верхнего уровня.
Кроме того, способ отключения M3 имеет значение. Если он перестанет отвечать только из-за потери питания или отключения сетевого кабеля, то M2 не может знать, что его нет, и (с TCP )попытается отправить повторно. Но если он активно отключен, ОС на M3 может попытаться убедиться, что все активные сетевые подключения закрыты упорядоченным образом. В этом случае M2 получит сообщение о том, что соединение закрыто, и может удалить все неотправленные данные.
Сетевые буферы будут находиться внутри ОС, поэтому они не будут видны при дампе памяти процесса, но в конечном итоге процесс также может выполнять некоторую буферизацию. Аналогичные аргументы, вероятно, будут применяться и там, если процесс завершится при обнаружении ошибки при соединении с M3.
Все вышеперечисленное относится к данным, которые необходимо сохранить для дальнейшего использования. Кроме того, вполне возможно, что некоторые данные остаются в памяти M2, в буферах, которые уже не используются, но фактически не были перезаписаны. Было бы интересно провести этот эксперимент с некоторыми простыми -в -идентифицируемыми данными,а затем сбросить память всей ОС, чтобы найти ее остаточные копии.
В зависимости от вашей модели угрозы вы также можете рассмотреть случай, когда программа на M2 или сама ОС скомпрометированы и отправляют копии сообщения неизвестной стороне.