Проблемы безопасности.

В современном мире, безопасность вызывает все большее беспокойство. Мы будем обсуждать реализации подходов безопасности по мере того как они появятся в книге. Тем не менее несколько основных понятий, стоит упомянуть прямо сейчас.

Любая проверка безопасности в системе вынуждается кодом ядра. Если в ядре есть «уязвимость» в безопасности, тогда и система в целом «уязвимая». В официальном дистрибутиве ядра, только авторизированный пользователь может загрузить модуль, системный вызов init_module проверяется если вызываемый процесс идентифицирован в системе тогда модуль загружается в ядро. Так когда запускается служебное ядро, только суперпользователь или человек который сменил при входе свои права, может взяться за управление привилегированного кода.

[1] Технически, только кто-то с правами доступа CAP_SYS_MODULE может выполнять эту операцию. Права доступа мы рассмотрим в шестой главе.

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

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

Есть несколько других подходов, которых стоит придерживаться. Любой полученный ввод информации от процесса пользователя должен быть обработан с огромным подозрением, ни когда не надейтесь на него пока не проверите все. Будьте внимательны с не инициированной памятью, любая память достигает ядра должна быть обнулена или другим образом про инициирована до того как будет доступна для пользовательского процесса или устройства. Иначе, результатом может быть оказаться утечка информации (обнаружение информации, паролей и т.д.). Если ваше устройство интерпретирует отправку данных к ядру, вы должны быть уверены что пользователь не может послать ничего что может причинить вред системе. Наконец, подумайте о возможных результатах от операций устройства; если есть какие-то особенные операции (на пример, перезагрузка фирменного программного обеспечения на соединительном устройстве или форматирование диска) которые могут воздействовать на систему, то они должны непременно ограничиваться правами пользователя.

Также, будьте внимательны, когда получаете программное обеспечение от третей стороны, особенно когда они обращаются к ядру: потому что любой кто имеет доступ и исходному коду, может сломать и пере компилировать. Хотя вы можете обычно довериться на заранее откомпилированные ядра в вашем дистрибутиве, вы должны избегать запуск ядра откомпилированного не надёжными друзьями, если вы не можете запустить заранее откомпилированное бинарный файл от имени суперпользователя, тогда вы лучше не запускайте заранее откомпилированное ядро. На пример, злонамеренно модифицированное ядро может разрешить любому загрузить модуль, так открыть неожиданную заднюю дверь через init_module.

Помните что ядро Линукс может быть откомпилированы без поддержки модуля, так закрытие любого связанного модуля может оказаться «уязвимостью» в безопасности. В этом дело, конечно, все необходимые драйвера должны бить построены прямо в ядре. Это тоже возможно, с ядром 2.2 и более поздних издательствах ядра, запрещая загрузку модулей ядра, после того как система загрузится через возможный механизм.