Есть ли способ обнулить SIGSTOP для определенного скрипта?

Question

Я создал сценарий и хочу, чтобы он был практически «невосприимчив» к SIGSTOP.
Я понимаю, что и SIGKILL, и SIGSTOP не могут быть перехвачены или проигнорированы. Я знаю, что система инициализации для Linux не может получить "фатальный" сигнал из-за того, что на его флагах структуры сигналов есть флаг SIGNAL_UNKILLABLE (хотя вторая половина этого предложения по большей части пролетает над моей головой).
Я готов отредактировать свое ядро, чтобы предоставить этому скрипту иммунитет, единственная проблема - я не знаю как. Итак, мой вопрос, есть ли способ обнулить SIGSTOP для определенного сценария / процесса?

Мне удалось разобраться с SIGKILL благодаря параметру Restart в служебном файле для моего скрипта (с использованием systemd), и хотя я просматривал руководства в поисках чего-то похожего для приостановленных процессов, я не смог пока что нашел.

Есть ли что-нибудь похожее на Restart = всегда для приостановки процесса, вызванного SIGSTOP?

Я бы не хотел go через процесс изменения вещей или связанных с ядром, но если это единственный способ, которым я буду.

Спасибо.

Answer 1

Хорошо, поэтому лучшее решение, которое я могу найти, - это SE Linux.

SE Linux - это надстройка ядра, созданная NSA, которая позже была выпущена для публикации c. Он обычно используется в системах Linux и поставляется по умолчанию на устройствах Android. SE Linux позволяет создавать "контексты". Контексты - это дополнительная метка, предоставляемая файлам и процессам, которая позволяет разделить ответственность и разрешения.

Как это решает вашу проблему? Ну, вы можете ограничить свои права доступа SE Linux для своих пользовательских процессов (даже для пользователя root), так что вам даже не разрешат сигнализировать об этом другом процессе вообще. На самом деле, вы можете предотвратить любое взаимодействие с ним вообще. Если вы хотите, вы можете go настолько, чтобы помешать себе даже отключить SE Linux (хотя, вероятно, лучше этого не делать, если вы можете избежать этого с оперативной точки зрения). Это на некотором уровне, вероятно, ближе всего к решению, которое находится где-то рядом с диапазоном не взломанных. При этом настройка и конфигурация SE Linux для этой цели не совсем прогулка в парке. Документация ограничена (но существует), distro-speci c, а в некоторых случаях даже esoteri c. У меня есть некоторый опыт работы с SE Linux.

Редактировать: При некотором быстром поиске, кажется, можно установить SE Linux на Arch, но, как и большинство вещей на Arch, это требует определенных усилий - больше чем должно поместиться в блоке комментариев StackOverflow. Однако я кратко опишу здесь ваш набор целей после установки SE Linux:

• Определите контекст, в котором вы находитесь. Использование команды "id" должно обеспечить этот контекст.
• Используйте переход процесса контекста , чтобы при выполнении сценария этот сценарий выполнялся в новом контексте. Вероятно, вам потребуется создать новый контекст для запуска вашего скрипта.
• Создайте отдельные правила, позволяющие этому скрипту взаимодействовать с вашими процессами так, как вам нужно. Возможно, это включает в себя возможность убивать другие процессы в другом контексте или читать из порта tcp с помощью сниффинга, et c. и др c. Вы можете использовать программу audit2allow , чтобы помочь вам создать эти правила.

По умолчанию SE Linux запрещает все, что явно не разрешено. Теперь ваша цель - убедиться, что все, что вы хотите делать в своей системе, разрешено, и добавить правила политики, разрешающие все эти вещи. Просмотр журналов аудита SE Linux - это отличный способ увидеть все, на что жалуется SE Linux - это ваша работа - go и преобразовать все эти ошибки аудита в «разрешающие» правила.

После того, как все это будет сделано, просто убедитесь, что вы не можете "разрешить" какой-либо контекст, в котором запускаются ваши процессы / оболочка, из-за возможности уничтожить или сигнализировать о контексте, в котором работает ваш скрипт, и все должно быть сделано. Теперь попытка SIGSTOP или SIGKILL должна генерировать «Ошибка отказа в доступе».