Я тут подумал - наверное не все так гладко.

Похоже cups умеет во время работы исправлять эти файлы

Как минимум он меняет статус принтера на Stopped на лету если с на него не удается отправить задание.
Возможно аналогичное поведение и с остальными конфигурационными файлами - я пока еще не успел посмотреть

Я тут подумал - наверное не все так гладко.

Похоже cups умеет во время работы исправлять эти файлы

Как минимум он меняет статус принтера на Stopped на лету если с на него не удается отправить задание.
Возможно аналогичное поведение и с остальными конфигурационными файлами - я пока еще не успел посмотреть

Это, по-моему, само по себе плохо: динамически меняющуюся информацию нужно хранить в другом месте (/var/). /etc может быть mounted read-only -- при нормальной работе, а не конфигурации системы, нет необходимости менять что-то в /etc/. (/etc/adjtime мешается, правда.)

Это, по-моему, само по себе плохо: динамически меняющуюся информацию нужно хранить в другом месте (/var/). /etc может быть mounted read-only -- при нормальной работе, а не конфигурации системы, нет необходимости менять что-то в /etc/. (/etc/adjtime мешается, правда.)

Это конечно все хорошо, но эта информация все-таки динамически меняется
только при конфигурировании. Так что перенос этой конфигурации в /var 
не целесообразен.

Это конечно все хорошо, но эта информация все-таки динамически меняется
только при конфигурировании. Так что перенос этой конфигурации в /var 
не целесообразен.

Боюсь, что скорее удасться переписать CUPS чем зафиксить это

Боюсь, что скорее удасться переписать CUPS чем зафиксить это

Хочу прокомментировать.

Хочу прокомментировать.

А если информация таки меняется только при кофигурировании, то пользователю lp не нужно владеть правами на её изменение -- ведь для конфигурации у нас специальный режим (admrestart и т.д.), при котором как раз сервер работает под root и не принимает запросов. Именно этого и хочется: чтобы ошибка в обработчике запросов на печать не могла привести к изменению конфигурационного файла не авторизованным пользователем и, как следствие, получению им прав root (через некоторое время). Запросы обрабатываются под lp, поэтому желательно, чтобы lp  не имел права записи в конфигурационный файл cups.


Кстати, вот пример когда этим можно было бы воспользоваться:

<a href="http://www.idefense.com/advisory/12.19.02.txt">http://www.idefense.com/advisory/12.19.02.txt</a>

смотрим только на Issue 1 -- можно получить shell под lp:

The exploit created a set user id \'lp\' shell. While the current exploit
works only against systems utilizing glibc-2.2.4-18.7.0.8, it is possible
to make modifications that will make it effective against earlier glibc
versions. The vulnerable code also exists in the latest version of CUPS
(test platform [3]) and appears to be exploitable with slight
modifications.

Казалось бы, страшно, но не очень.

Но так как конфигурационный файл доступен на запись lp, злоумышленник может поменять в нём свойства запуска сервера: заменить пользователя lp на пользователя root -- запросы на печать будут обрабатываться под root.  И теперь, после очередного перезапуска cups ничего не заметившим администратором, повторяя те же действия получает shell под root.


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

А если информация таки меняется только при кофигурировании, то пользователю lp не нужно владеть правами на её изменение -- ведь для конфигурации у нас специальный режим (admrestart и т.д.), при котором как раз сервер работает под root и не принимает запросов. Именно этого и хочется: чтобы ошибка в обработчике запросов на печать не могла привести к изменению конфигурационного файла не авторизованным пользователем и, как следствие, получению им прав root (через некоторое время). Запросы обрабатываются под lp, поэтому желательно, чтобы lp  не имел права записи в конфигурационный файл cups.


Кстати, вот пример когда этим можно было бы воспользоваться:

<a href="http://www.idefense.com/advisory/12.19.02.txt">http://www.idefense.com/advisory/12.19.02.txt</a>

смотрим только на Issue 1 -- можно получить shell под lp:

The exploit created a set user id \'lp\' shell. While the current exploit
works only against systems utilizing glibc-2.2.4-18.7.0.8, it is possible
to make modifications that will make it effective against earlier glibc
versions. The vulnerable code also exists in the latest version of CUPS
(test platform [3]) and appears to be exploitable with slight
modifications.

Казалось бы, страшно, но не очень.

Но так как конфигурационный файл доступен на запись lp, злоумышленник может поменять в нём свойства запуска сервера: заменить пользователя lp на пользователя root -- запросы на печать будут обрабатываться под root.  И теперь, после очередного перезапуска cups ничего не заметившим администратором, повторяя те же действия получает shell под root.


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

In \"non-insecure\" mode files must be available only for root.

In \"non-insecure\" mode files must be available only for root.

надо смотреть, проверять и доделывать cups-1.1.18-alt2

надо смотреть, проверять и доделывать cups-1.1.18-alt2