The configuration is default (i.e. User lp). After package installation /etc/cups/cupsd.conf is owned by root, group root (this is right). But after \'service cups restart\' the owner is changed: $ l /etc/cups/cupsd.conf -rw------- 1 lp lp 17943 Jun 18 01:00 /etc/cups/cupsd.conf (rpm -V cups report this, too). This is quite bad from the security point of view: theoretically, a normal user could get root\'s permissions in two steps. The first step: find a hole in a filter that used by CUPS for processing input data before printing; this hole should allow to write to a file. (In practice, no such hole is known, but it is quite possible to exist.) Then the user forms a special request to CUPS which uses this hole to overwrite /etc/cups/cupsd.conf (it is owned by lp, and the filters are run as lp): he puts \"User root\" there. The second step: after restarting CUPS (system reboot) the new configuration is active, the filters are run as root, and it is possible to get access to any data in the system by quite simple Postscript requests (this is practically implementable, very simple; never use \"User root\"!). So he can read any private keys, any private data, and probably also rewrite it (since the first step succeeded). So he can get a root shell or whatever he wants. --- apt-get remove cups apt-get install cups rpm -V cups service cups restart rpm -V cups l /etc/cups/cupsd.conf --- cups-1.1.15-alt2 (some previous releases also behave like this). (I\'m making this report in order no to forget about this bug.) As you know, CUPS is not secure at how he protects the data in the printing queue. (If you use CUPS, then the data you print can be stolen by another user without much trouble.) But that is not as bad as the described misbehavior, since that doesn\'t compromise the rest of the system.
Я тут подумал - наверное не все так гладко. Похоже cups умеет во время работы исправлять эти файлы Как минимум он меняет статус принтера на Stopped на лету если с на него не удается отправить задание. Возможно аналогичное поведение и с остальными конфигурационными файлами - я пока еще не успел посмотреть
Это, по-моему, само по себе плохо: динамически меняющуюся информацию нужно хранить в другом месте (/var/). /etc может быть mounted read-only -- при нормальной работе, а не конфигурации системы, нет необходимости менять что-то в /etc/. (/etc/adjtime мешается, правда.)
Это конечно все хорошо, но эта информация все-таки динамически меняется только при конфигурировании. Так что перенос этой конфигурации в /var не целесообразен.
Боюсь, что скорее удасться переписать 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, сильно повышает степень угрозы от возможных дырок в обработчиках заданий на печать (разные типы данных, фильтры, драйверы для принтеров). А их все проверить довольо тяжело, по-моему, были сообщения о найденных (и исправленных) дырах в них.
In \"non-insecure\" mode files must be available only for root.
надо смотреть, проверять и доделывать cups-1.1.18-alt2
