Кратко
- COPS превратил знакомые проблемы Unix — слабые пароли, чрезмерные права доступа и открытые стартовые файлы — в повторяемые проверки локального узла.
- Настраиваемые небольшие программы сообщали о возможных проблемах, но не исправляли их. Большинство не требовало root; более полный поиск SUID-файлов выполнялся отдельно и нуждался в привилегиях.
- Чистый отчёт описывает заданные проверки и их фактический охват на момент запуска. Он не подтверждает полную безопасность и неизменность узла после проверки.
Повторный поиск обычных ошибок
Статья 1990 года начинается с практического наблюдения: в материалах по безопасности Unix постоянно обсуждались одни и те же недостатки. Программы SUID, слишком широкие права на файлы и слабые пароли часто было несложно исправить после обнаружения. Труднее было регулярно искать их в меняющихся установках. Farmer и Spafford хотели сделать такую проверку повторяемой.
COPS означает “Computerized Oracle and Password System”, но это не сетевой сканер. Главный shell-сценарий собирал результаты примерно дюжины подпрограмм и отправлял их местному администратору по почте либо записывал в файл. Большинство компонентов использовало Bourne shell и стандартные средства Unix; при необходимости добавлялись небольшие программы на C. Компоненты можно было менять под конкретную площадку.
Проверялись конкретные административные объекты: доступные всем для записи файлы и каталоги из заданного списка; пароли, совпадающие с именем пользователя или состоящие из распространённых слов; ошибки в файлах учётных записей и групп; доступные для изменения файлы, вызываемые cron или стартовыми сценариями; права на отдельные устройства; домашние каталоги и файлы инициализации; umask и пути поиска в стартовых файлах root. suidchk сравнивал набор SUID-файлов с предыдущим запуском. Kuang применял правила, чтобы выяснить, мог ли пользователь по этим правилам достичь состояния компрометации целевой учётной записи.
Именно эта ограниченная предметность объясняет ценность COPS лучше, чем обещание «просканировать безопасность». Инструмент удешевлял повторение известного набора локальных проверок, но не охватывал все возможные дефекты и не решал, противоречит ли каждое право политике конкретной организации.
Отчёт не исправлял узел
Авторы намеренно сделали COPS средством наблюдения, а не изменения системы. У двух узлов с похожими аппаратурой и версией Unix могут быть разные задачи, данные и требования к доступу. Допустимая настройка в одном месте может быть неприемлемой в другом. Автоматическое исправление превратило бы техническую находку в решение о политике, для которого программе не хватало контекста.
Ограничение касалось и привилегий. В статье говорится, что инструменты, кроме поиска SUID-файлов, не предназначались для запуска от root. Поиск SUID обычно выполняли отдельно: он мог занимать больше времени и требовал доступа к каталогам, недоступным обычной учётной записи. Это снижало привилегии для повседневных проверок, но делало охват отчёта зависимым от способа запуска каждого компонента.
Авторы советовали регулярные запуски через at или cron: проблема, которой сегодня нет или которую не обнаружили, может возникнуть позже. Расписание не обеспечивает полноту. Изменённая программа или список путей способны ввести в заблуждение; злоумышленник может прочитать отчёты или подменить проверку; повторные чистые результаты могут привести к самоуспокоенности. Изменение работы системы также способно породить недостатки вне прежнего набора проверок.
Границы свидетельств
Farmer и Spafford получили отзывы от академических, государственных и коммерческих площадок. Они сообщили, что более чем в половине проверенных систем или систем из полученных отзывов были проблемы, способные привести к компрометации root. При этом авторы прямо сказали, что не знают, можно ли перенести это ограниченное наблюдение на большую совокупность. Это не оценка для всех систем Unix.
COPS и более поздний SATAN, связанный с Farmer, изучали разные поверхности: локальные учётные записи, файлы, права и запуск Unix у первого; сетевые службы и видимую другим узлам экспозицию у второго. Общий автор не делает их отчёты взаимозаменяемыми.
Note 65 Хенга Лу здесь служит только редакционной оптикой: выводы о работающей системе должны оставаться в пределах наблюдений выполненной проверки. Для COPS важно установить, какие тесты запускались, с какими правами, по каким путям и когда. Автоматизация облегчает повторение списка, но администратор по-прежнему определяет охват, защищает отчёты, толкует результаты и выбирает исправления.
Источники
- Farmer и Spafford, “The COPS Security Checker System” (первоисточник)
- Библиография USENIX: материалы летней конференции 1990 года
- Eugene H. Spafford, воспоминание CERIAS о COPS
- Purdue CERIAS, “Firsts” Спэффорда
- Только редакционная оптика: Heng Lu, Note 65, “Running-Code Primacy”
- Только для подтверждения личности: публичный портрет Dan Farmer на Wikimedia Commons
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
