Почему некоторые процессы не могут работать в фоновом режиме в терминале Linux, а другие могут, несмотря на то, что все они могут печатать на терминале?

Я запускаю Debian 9 с включенной безопасной загрузкой и самоподписанными -ключами. Это, безусловно, может защитить от тривиальных атак типа Evil Maid -, таких как подключение загрузочного USB-накопителя для захвата данных из вашей системы или установки вредоносного ПО на незашифрованные -разделы. Но это вряд ли предел возможностей Злой Девы :, если вы серьезно относитесь к этому, вы также должны подумать о физической безопасности шасси системы.

Для «ретроактивных» проверок целостности вам потребуется чип TPM и загрузчик, который будет использовать его регистры PCR. Эти регистры не могут быть просто установлены на любое значение :, когда новые данные передаются в эти регистры, микросхема TPM сама вычислит хэш старого значения регистра + ввод данных и назначит это как новое значение регистра. регистр. Системная прошивка заполнит первые несколько регистров PCR хэшами самой прошивки, текущими настройками прошивки и первым фрагментом загрузочного кода, который фактически использовался. После этого управление будет передано этому загрузочному коду.

Если вы использовали загрузчик, который аналогичным образом записывает хэши файлов ядра и initramfs, фактически загруженных в регистры PCR, вы могли бы сверить значения PCR с набором «заведомо исправных» значений, хранящихся в зашифрованной части диска.,и отображать предупреждение, если текущие значения не будут соответствовать известному -хорошему состоянию. Ядро также имеет параметр CONFIG _IMA, который при активации заставляет ядро ​​использовать один регистр PCR TPM для хранения хэшей всего, что оно загрузило. (Хэш хэшей, так как TPM не особенно быстр. :Отправка полной копии всех загруженных данных в TPM для хэширования может значительно замедлить процесс загрузки.)

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

Несколько лет назад, когда я экспериментировал с TPM PCR, это была система с устаревшей прошивкой BIOS. С помощью TrustedGRUB (в основном версии GRUB Legacy )с поддержкой TPM -я смог реализовать тип проверки, описанный в предыдущем абзаце. Я не уверен, есть ли загрузчик Linux UEFI с поддержкой TPM, поэтому вы можете не получить полного охвата PCR ранней системы, если только вы не загружаетесь, используя только встроенный в ядро ​​-загрузчик-заглушку UEFI (, поэтому прошивка в конечном итоге запишет хеш самого ядра, а не только загрузчика ).

0
17.09.2020, 18:21
2 ответа

lessне может работать в фоновом режиме, поскольку пытается взаимодействовать с управляющим терминалом, что приводит к его принудительной остановке. Только процесс переднего плана может читать с терминала или изменять настройки терминала.

Когда фоновый процесс пытается изменить настройки терминала, он получает сигнал SIGTTOU. Когда он пытается прочитать с терминала, он получает сигнал SIGTTIN. Оба сигнала вызывают его остановку. Если процесс продолжается и игнорирует эти сигналы, операции, вызвавшие их, могут завершиться неудачей, так что это не выход из этого (, например. чтение с терминала завершится с ошибкой EIO).

Примечания:

lessотличается тем, что для того, чтобы его можно было использовать как command | less, он открывает управляющий терминал напрямую через /dev/ttyвместо того, чтобы предполагать, что управляющий терминал является его стандартным вводом или выводом, как другие интерактивные программы, такие как большинство редакторов или оболочек делают.

Вы можете настроить свой терминал с помощью stty tostop, чтобы фоновые программы, которые пытаются записать на управляющий терминал, также будут остановлены, но это нигде не используется по умолчанию, и это не очень практично.

3
18.03.2021, 23:04

Потому что ему нужен доступ к терминалу.

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

Process1: important data(bg)    you type      Process2: just a quiz-game (fg)
output                                        output
                                             
Do you want to quit(q) or                     How do you call a group of 5 
   continue (c)                                     music players?
                          <-      q

OK, quit, save data?              u     ->
                                  i     ->
                          <-      n
                                  t     -> 
Ok destroyed all data.            e     ->
                                  t     ->
                                 <enter>->           Wrong answer: uitet.

В качестве примера, чтобы увидеть, как это работает, вы можете использовать следующий скрипт:

#!/bin/bash

while read sentence ; do
        echo "$sentence"
        echo '----------------'
        head -1 /dev/tty
done

Обычный readсчитывает ввод из STDIN. Вы можете перенаправить на него что угодно. head -1 /dev/ttyбудет принудительно вводить данные с терминала. Если вы работаете на переднем плане, сценарий будет давать вам строку для каждого введенного вами ввода.

Если вы запустите этот сценарий в фоновом режиме, cat tst.sh | bash tst.sh &он остановится в точке, где вы явно требуете ввода с терминала.

1
18.03.2021, 23:04

Теги

Похожие вопросы