Bug 31636 - Нарушает ALT Secure Packaging Policy
Summary: Нарушает ALT Secure Packaging Policy
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: syslog-common (show other bugs)
Version: unstable
Hardware: all Linux
: P3 blocker
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL: https://www.altlinux.org/Secure_Packa...
Keywords:
: 32011 (view as bug list)
Depends on:
Blocks: 30940 34231
  Show dependency tree
 
Reported: 2015-12-17 08:00 MSK by Evgenii Terechkov
Modified: 2020-02-26 16:42 MSK (History)
13 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Evgenii Terechkov 2015-12-17 08:00:21 MSK
Пакет нарушает ALT Secure Packaging Policy, на что ежедневно в почту жалуется logrotate (3.9.1-alt2 и выше):

=8<=======================================================================
error: skipping "/var/log/uucp/Debug" because parent directory has insecure
permissions (it's not owned by "root"); consider using "su" directive in config
file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/uucp/Log" because parent directory has insecure
permissions (it's not owned by "root"); consider using "su" directive in config
file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/uucp/Stats" because parent directory has insecure
permissions (it's not owned by "root"); consider using "su" directive in config
file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/uucp/errors" because parent directory has insecure
permissions (it's not owned by "root"); consider using "su" directive in config
file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/uucp/info" because parent directory has insecure
permissions (it's not owned by "root"); consider using "su" directive in config
file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/log/uucp/warnings" because parent directory has insecure
permissions (it's not owned by "root"); consider using "su" directive in config
file to tell logrotate which user/group should be used for rotation.
=8<=======================================================================

Полиси гласит:
=8<=======================================================================
Пакеты не должны содержать каталоги, принадлежащие псевдо-пользователям. Вместо этого следует использовать каталоги, принадлежащие root, с установленным sticky bit и доступом группы по записи.
=8<=======================================================================

Таким образом, пользователи пакетов postfix, openvpn, nut-server и, видимо, всех реализации syslog, установившие новый logrotate, сейчас каждый день получают такие вот письма.

P.S.: предыстория здесь: https://bugzilla.altlinux.org/show_bug.cgi?id=31623

P.P.S.: согласно определению ldv в багтрекере, пакеты нарушающие SPP это блокер для выпуска продуктов, основанных на сизифе (цитата не дословная).
Comment 1 Dmitry V. Levin 2015-12-17 13:10:03 MSK
(In reply to comment #0)
> Пакет нарушает ALT Secure Packaging Policy, на что ежедневно в почту жалуется
> logrotate (3.9.1-alt2 и выше):
> 
> =8<=======================================================================
> error: skipping "/var/log/uucp/Debug" because parent directory has insecure
> permissions (it's not owned by "root"); consider using "su" directive in config
> file to tell logrotate which user/group should be used for rotation.
> error: skipping "/var/log/uucp/Log" because parent directory has insecure
> permissions (it's not owned by "root"); consider using "su" directive in config
> file to tell logrotate which user/group should be used for rotation.
> error: skipping "/var/log/uucp/Stats" because parent directory has insecure
> permissions (it's not owned by "root"); consider using "su" directive in config
> file to tell logrotate which user/group should be used for rotation.

Какой софт создает эти три файла?  Если изменим владельца каталога, кто-нибудь потеряет туда доступ?
Comment 2 Evgenii Terechkov 2015-12-17 13:27:25 MSK
Создаёт пакет uucp:
=8<=====================================================
evg@thinkpad ~ $egrep '/var/log/uucp/[A-Z]' RPM/contents_index.*
RPM/contents_index.x86_64:/var/log/uucp/Debug   uucp
RPM/contents_index.x86_64:/var/log/uucp/Log     uucp
RPM/contents_index.x86_64:/var/log/uucp/Stats   uucp
=8<=====================================================

Видимо, потеряет. Возможно, его потребуется обновить.
Comment 3 Evgenii Terechkov 2015-12-28 08:27:22 MSK
Впрочем, судя по правам на исполнимые файлы пакета uucp мне кажется что смена прав на root:uucp ничего не сломает:

=8<===========================================================================
root@thinkpad ~ #rpm -qvl uucp |egrep -v "^d"|awk '{print $9}'|xargs egrep -c "\b(Stats|Debug)\b"|egrep -iv :0$ |grep -v /usr/share/doc/uucp|aw
k -F: '{print $1}'|xargs ls -l |sort
-r-s--s--x 1 uucp uucp  47648 Apr 19  2013 /usr/bin/uuname
-r-s--s--x 1 uucp uucp 113504 Apr 19  2013 /usr/bin/uucp
-r-s--s--x 1 uucp uucp 117592 Apr 19  2013 /usr/bin/uux
-r-s--s--x 1 uucp uucp 125880 Apr 19  2013 /usr/bin/uustat
-r-s--s--x 1 uucp uucp 129944 Apr 19  2013 /usr/sbin/uuxqt
-r-s--s--x 1 uucp uucp 162968 Apr 19  2013 /usr/bin/cu
-r-s--s--x 1 uucp uucp 283576 Apr 19  2013 /usr/sbin/uucico
-rwxr-xr-x 1 root root  80448 Apr 19  2013 /usr/bin/uulog
-rwxr-xr-x 1 root root  88744 Apr 19  2013 /usr/bin/uupick
-rwxr-xr-x 1 root root  92512 Apr 19  2013 /usr/sbin/uuchk
-rwxr-xr-x 1 root root  92536 Apr 19  2013 /usr/sbin/uuconv
=8<===========================================================================

В любом случае, насколько я понимаю, у пакета uucp на порядки меньше пользователей чем у syslog-common, так что было бы оправдано привести syslog-common к SPP даже ценой поломки uucp (который можно починить без спешки после).

Я попробовал собрать syslog-common согласно SPP, код у меня в git, бранч bug-31636 (http://git.altlinux.org/people/evg/packages/?p=sysklogd.git;a=commitdiff;h=10e85d118934593ec886df799c1aa735bcc435bf). На моих машинах это вроде бы починило данный баг. Но надо учитывать, что uucp полноценно протестировать мне просто не на чем (он у меня стоит исторически ради программы cu). Прошу проверить/поругать/собрать/дать ACL/...
Comment 4 Dmitry V. Levin 2015-12-29 03:29:52 MSK
(In reply to comment #3)
> Впрочем, судя по правам на исполнимые файлы пакета uucp мне кажется что смена
> прав на root:uucp ничего не сломает:
> 
> =8<===========================================================================
> root@thinkpad ~ #rpm -qvl uucp |egrep -v "^d"|awk '{print $9}'|xargs egrep -c
> "\b(Stats|Debug)\b"|egrep -iv :0$ |grep -v /usr/share/doc/uucp|aw
> k -F: '{print $1}'|xargs ls -l |sort
> -r-s--s--x 1 uucp uucp  47648 Apr 19  2013 /usr/bin/uuname
> -r-s--s--x 1 uucp uucp 113504 Apr 19  2013 /usr/bin/uucp
> -r-s--s--x 1 uucp uucp 117592 Apr 19  2013 /usr/bin/uux
> -r-s--s--x 1 uucp uucp 125880 Apr 19  2013 /usr/bin/uustat
> -r-s--s--x 1 uucp uucp 129944 Apr 19  2013 /usr/sbin/uuxqt
> -r-s--s--x 1 uucp uucp 162968 Apr 19  2013 /usr/bin/cu
> -r-s--s--x 1 uucp uucp 283576 Apr 19  2013 /usr/sbin/uucico
> -rwxr-xr-x 1 root root  80448 Apr 19  2013 /usr/bin/uulog
> -rwxr-xr-x 1 root root  88744 Apr 19  2013 /usr/bin/uupick
> -rwxr-xr-x 1 root root  92512 Apr 19  2013 /usr/sbin/uuchk
> -rwxr-xr-x 1 root root  92536 Apr 19  2013 /usr/sbin/uuconv
> =8<===========================================================================
> 
> В любом случае, насколько я понимаю, у пакета uucp на порядки меньше
> пользователей чем у syslog-common, так что было бы оправдано привести
> syslog-common к SPP даже ценой поломки uucp (который можно починить без спешки
> после).
> 
> Я попробовал собрать syslog-common согласно SPP, код у меня в git, бранч
> bug-31636
> (http://git.altlinux.org/people/evg/packages/?p=sysklogd.git;a=commitdiff;h=10e85d118934593ec886df799c1aa735bcc435bf).
> На моих машинах это вроде бы починило данный баг. Но надо учитывать, что uucp
> полноценно протестировать мне просто не на чем (он у меня стоит исторически
> ради программы cu). Прошу проверить/поругать/собрать/дать ACL/...

У меня это изменение, пожалуй, ничего не сломает, но ведь у меня и пакет uucp не установлен. Давайте лучше спросим мантейнера пакета uucp.
Comment 5 Evgenii Terechkov 2015-12-29 04:02:38 MSK
Я думал, у пакета uucp есть/остались только пользователи :-)
Comment 6 Dmitry V. Levin 2015-12-29 04:11:38 MSK
(In reply to comment #5)
> Я думал, у пакета uucp есть/остались только пользователи :-)

Остались пользователи?  Да вы, оказывается, оптимист!
Comment 7 Evgenii Terechkov 2015-12-29 04:38:39 MSK
Я, например (за счёт программы cu).
Comment 8 Sergey Bolshakov 2015-12-29 13:43:07 MSK
ого, я оказывается майнтайнер программы cu.
а давайте я её отдельно запакую
Comment 9 Evgenii Terechkov 2016-03-18 06:08:15 MSK
ping?
Comment 10 Evgenii Terechkov 2016-04-13 18:42:11 MSK
cu теперь в отдельном подпакете.

Дмитрий, как насчёт предложенного изменения в sysklogd?
Comment 11 Evgenii Terechkov 2016-04-22 08:08:19 MSK
*** Bug 32011 has been marked as a duplicate of this bug. ***
Comment 12 Sergey Y. Afonin 2016-04-22 09:49:35 MSK
(In reply to comment #11)

> *** Bug 32011 has been marked as a duplicate of this bug. ***

Может, добавить su в секцию ротации для uucp, а дальше решать, что и как делать по-правильному ? Что-то делать уже надо, p8 выпускать в таком виде странно.
Comment 13 Sergey Y. Afonin 2016-04-22 13:38:55 MSK
(In reply to comment #6)

> > Я думал, у пакета uucp есть/остались только пользователи :-)
> 
> Остались пользователи?  Да вы, оказывается, оптимист!

Кстати, можно просто убрать упоминание uucp из syslog-common, а на uucp повесить баг о необходимости решить вопрос с логами со ссылкой на этот баг. Пусть с ним мантейнер uucp разбирается, если объявится.
Comment 14 Evgenii Terechkov 2016-09-17 20:46:32 MSK
Открыл для себя ckermit. Но всё же:

ldv@, ping?
Comment 15 Sergey Y. Afonin 2016-11-11 11:47:49 MSK
(In reply to comment #13)
> (In reply to comment #6)
> 
> > > Я думал, у пакета uucp есть/остались только пользователи :-)
> > 
> > Остались пользователи?  Да вы, оказывается, оптимист!
> 
> Кстати, можно просто убрать упоминание uucp из syslog-common, а на uucp
> повесить баг о необходимости решить вопрос с логами со ссылкой на этот баг.
> Пусть с ним мантейнер uucp разбирается, если объявится.

Или сделать комплексно: uucp из syslog-common убрать, одновременно в uucp упаковать /var/log/uucp в том виде, как оно сейчас в syslog-common и добавить правило для logrotate c su:

/var/log/uucp/* {
        su uucp adm
        rotate 5
        weekly
        postrotate
                /sbin/reload-syslog >/dev/null
        endscript
}

И можно отметить багом на пакет uucp, что надо понять, что с этим делать.
Comment 16 viy 2016-11-18 15:01:13 MSK
у меня на всех repo нодах этот баг:( 
забивает почту мусором, что неприятно, так как почта - один из индикаторов
проблем с нодой.

Проблема, как я понимаю в жестком acl=ldv.

Дмитрий, вы будете чинить или поручите кому?
Comment 17 Dmitry V. Levin 2016-11-18 15:10:25 MSK
(In reply to comment #16)
> у меня на всех repo нодах этот баг:( 
> забивает почту мусором, что неприятно, так как почта - один из индикаторов
> проблем с нодой.
> 
> Проблема, как я понимаю в жестком acl=ldv.
> 
> Дмитрий, вы будете чинить или поручите кому?

Пакет syslog-common происходит из исходного пакета sysklogd, в котором есть более важные проблемы, требующие решения. Одна из них - починить собираемость пакета. В принципе понятно, как эти проблемы решать, но не вполне понятно, кто и когда это будет делать.
Comment 18 viy 2016-11-18 15:16:57 MSK
(In reply to comment #17)
> (In reply to comment #16)
> > Проблема, как я понимаю в жестком acl=ldv.
> > Дмитрий, вы будете чинить или поручите кому?
> Пакет syslog-common происходит из исходного пакета sysklogd, в котором есть
> более важные проблемы, требующие решения. Одна из них - починить собираемость
> пакета. В принципе понятно, как эти проблемы решать, но не вполне понятно, кто
> и когда это будет делать.

возможно, стоит тогда acl открыть? чтобы если кому припечет,
не жаловались, а могли исправить.
Comment 19 Sergey Y. Afonin 2017-01-15 12:42:31 MSK
*** Bug 32822 has been marked as a duplicate of this bug. ***
Comment 20 Sergey Y. Afonin 2017-06-08 11:43:09 MSK
(In reply to comment #17)

> В принципе понятно, как эти проблемы решать, но не вполне понятно, кто
> и когда это будет делать.

Похоже, кто-то нашёлся:
git://git.altlinux.org/people/boyarsh/packages/sysklogd.git

Я себе собрал. Делает вид, что работает.
Comment 21 Vitaly Lipatov 2017-07-20 16:33:10 MSK
Очень похоже, что пользователей пакета logrotate нет, или им cron не передаёт каждый час привет от logrotate.
Comment 22 Sergey Y. Afonin 2017-08-18 08:35:21 MSK
Антон, а какие препятствия мешают sysklogd 1.4.1-alt31 в Сизиф отправить?
Comment 23 Michael Shigorin 2017-08-22 09:13:34 MSK
А он не пересобирался после обновления glibc.  По этой части уже предприняты необходимые действия, но до сизифа результат ещё не добрался.
Comment 24 Vitaly Lipatov 2017-10-25 01:33:08 MSK
(В ответ на комментарий №23)
> А он не пересобирался после обновления glibc.  По этой части уже предприняты
> необходимые действия, но до сизифа результат ещё не добрался.
Посмотрел, что версия 1.4.1 прожила лет 17. С такими масштабами в ближайшие лет 5 ждать обновления даже в Сизифе не стоит.
Comment 25 Michael Shigorin 2017-10-26 19:57:19 MSK
(В ответ на комментарий №24)
> С такими масштабами в ближайшие лет 5 ждать обновления даже в Сизифе не стоит.
Думаю, к p9 всё-таки неизбежно придётся починить.
Comment 26 Sergey Y. Afonin 2017-11-07 10:45:15 MSK
(In reply to comment #23)

> А он не пересобирался после обновления glibc.  По этой части уже предприняты
> необходимые действия, но до сизифа результат ещё не добрался.

Может в p8 хотябы ?
Comment 27 Sergey Y. Afonin 2017-11-07 10:46:58 MSK
(In reply to comment #26)

> > А он не пересобирался после обновления glibc.  По этой части уже предприняты
> > необходимые действия, но до сизифа результат ещё не добрался.
> 
> Может в p8 хотябы ?

А, так надо как-то версию в Сизифе вырастить...
Comment 28 Vitaly Lipatov 2017-11-12 19:16:55 MSK
В случае отсутствия реакции мейнтейнера на ошибки с серьёзностью Blocker в bugzilla.altlinux.org в течение 12 часов следует добавить комментарий к ошибке с запросом на NMU и подготовить обновление.

Одновременно с заливкой NMU рекомендуется указать мейнтейнеру на git с исправлением (если мейнтейнер использует gear) либо приложить к ошибке в bugzilla.altlinux.org патч.

https://www.altlinux.org/NMU

Если исправление пакета готово, подготовьте task и напишите запрос на NMU.
Comment 29 Sergey Y. Afonin 2017-11-27 11:24:20 MSK
(In reply to comment #28)

> Если исправление пакета готово, подготовьте task и напишите запрос на NMU.

Проблема в том, что во всех репозиториях (как минимум от p5/5.1 и новее) версия sysklogd 1.4.1-alt30. В p8 он бы собрался, но невозможно сделать версию для p8 больше p7 и меньше Sisyphus. А в Sisyphus краткий момент возможности пересобрать упущен: Comment #23
Comment 30 Repository Robot 2018-08-29 01:40:48 MSK
syslog-common-2-alt1 -> sisyphus:

* Tue Aug 28 2018 Dmitry V. Levin <ldv@altlinux> 2-alt1
- Split syslog-common out of sysklogd package.
- Moved /etc/syslog.d to filesystem package.
- Fixed /var/log/uucp permissions (closes: #31636).
Comment 31 Evgenii Terechkov 2018-08-29 06:04:58 MSK
Ура, три года почти.
Comment 32 Sergey Y. Afonin 2020-02-26 16:42:25 MSK
(In reply to Michael Shigorin from comment #23)

> А он не пересобирался после обновления glibc.  По этой части уже предприняты
> необходимые действия, но до сизифа результат ещё не добрался.

Немного может быть поздно, но может имеет смысл отправить sysklogd 1.4.1-alt31 в p8, раз пакет теперь уже отсутствует в более свежих репозиториях?