Summary: | Osec игнорирует изменения selinux атрибутов | ||||||
---|---|---|---|---|---|---|---|
Product: | Sisyphus | Reporter: | nbr <nbr> | ||||
Component: | osec | Assignee: | Alexey Gladkov <legion> | ||||
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||
Severity: | enhancement | ||||||
Priority: | P3 | CC: | aen, darktemplar, imz, ldv, legion, manowar, mike, rider | ||||
Version: | unstable | ||||||
Hardware: | all | ||||||
OS: | Linux | ||||||
Attachments: |
|
Description
nbr
2019-09-13 12:18:10 MSK
как вы проверяет статус osec ? что говорит об этих файлах утилита osec ? а osec вообще должен отслеживать атрибуты selinux ? (In reply to comment #2) > а osec вообще должен отслеживать атрибуты selinux ? С 2012 умеет xattrs и с того же года он отслеживает selinux в них. (In reply to comment #1) > как вы проверяет статус osec ? > что говорит об этих файлах утилита osec ? Мне ответ всё же нужен. Проверяю при помощи osec.cron
Кстати, можно ли убрать жесткую зависимость osec на osec.cronjob?
это мешает портированию osec в с-бранчи, так как там osec такой же как в Сизифе, а osec.cronjob другой.
2019-10-04T17:23:04.419911+03:00 homerun osec[1664184]: Started
2019-10-04T17:23:05.216271+03:00 homerun denis: [osec] Daily security check (chg=0,add=0,del=0) -- homerun.localdomain
2019-10-04T17:23:05.242736+03:00 homerun osec[1664184]: Finished
[root@homerun osec]# osec2txt /var/lib/osec/osec.cdb.%2Fbin qq2
.dbver1/ osec.cdb.%2Fsbin osec.cdb.%2Fusr%2Flib64 osec.cdb.%2Fusr%2FX11R6%2Fbin temp/
osec.cdb.%2Fbin osec.cdb.%2Fusr%2Fbin osec.cdb.%2Fusr%2Flibexec osec.cdb.%2Fusr%2FX11R6%2Flib
osec.cdb.%2Flib osec.cdb.%2Fusr%2Fgames osec.cdb.%2Fusr%2Fsbin qq
osec.cdb.%2Flib64 osec.cdb.%2Fusr%2Flib osec.cdb.%2Fusr%2Fshare qq2
[root@homerun osec]# osec2txt /var/lib/osec/osec.cdb.%2Fbin aa1
[root@homerun osec]# /usr/share/osec/osec.cron
[root@homerun osec]# postdrop: warning: unable to look up public/pickup: No such file or directory
[root@homerun osec]# chcon -t officer_exec_t /bin/tcsh
[root@homerun osec]# /usr/share/osec/osec.cron
[root@homerun osec]# postdrop: warning: unable to look up public/pickup: No such file or directory
[root@homerun osec]# tail /var/log/messages
2019-10-04T17:23:18.563211+03:00 homerun nm-dispatcher: req:1 'dhcp4-change' [eth0]: new request (6 scripts)
2019-10-04T17:23:18.563246+03:00 homerun nm-dispatcher: req:1 'dhcp4-change' [eth0]: start running ordered scripts...
2019-10-04T17:24:11.724660+03:00 homerun osec[1668196]: Started
2019-10-04T17:24:11.801478+03:00 homerun denis: [osec] Daily security check (chg=0,add=0,del=0) -- homerun.localdomain
2019-10-04T17:24:11.805807+03:00 homerun osec[1668196]: Finished
2019-10-04T17:24:13.190276+03:00 homerun rsyslogd: -- MARK --
2019-10-04T17:24:52.815901+03:00 homerun osec[1670605]: Started
2019-10-04T17:24:52.882569+03:00 homerun denis: [osec] Daily security check (chg=0,add=0,del=0) -- homerun.localdomain
2019-10-04T17:24:52.886338+03:00 homerun osec[1670605]: Finished
root@homerun osec]# osec2txt /var/lib/osec/osec.cdb.%2Fbin aa2
[root@homerun osec]# diff aa1 aa2
1694c1694
< xattr="73656375726974792e73656c696e757800250000000000000067656e657269635f753a6f626a6563745f723a747275737465645f657865635f743a73320000" \
---
> xattr="73656375726974792e73656c696e757800250000000000000067656e657269635f753a6f626a6563745f723a6f6666696365725f657865635f743a73320000" \
[root@homerun osec]#
Ну и чтобы убедиться что ДРУГИЕ атрибуты отследились:
chmod 700 /bin/tcsh
[root@homerun osec]# /usr/share/osec/osec.cron
[root@homerun osec]# postdrop: warning: unable to look up public/pickup: No such file or directory
[root@homerun osec]# tail /var/log/messages
2019-10-04T17:24:52.882569+03:00 homerun denis: [osec] Daily security check (chg=0,add=0,del=0) -- homerun.localdomain
2019-10-04T17:31:56.609134+03:00 homerun osec[1694803]: Started
2019-10-04T17:31:56.665089+03:00 homerun denis: [osec] Daily security check (chg=1,add=0,del=0) -- homerun.localdomain
2019-10-04T17:31:56.669170+03:00 homerun osec[1694803]: Finished
немного ошибся: s/osec.cronjob/osec-cronjob/ и osec-mailreport тоже Их бы выделить в отдельный подпакет. Среди этого вывода нет того чего я просил. Вот вывод с моей машины на fedora (хотя это не важно для osec): $ src/osec -v |grep ver osec version 1.2.9 $ src/osec -r -D ~/tmp/osec-db ~/tmp/osec Processing /home/legion/tmp/osec ... /home/legion/tmp/osec/bash xattr changed security.selinux unconfined_u:object_r:user_tmp_t:s0 -> unconfined_u:object_r:bin_t:s0 $ src/osec -r -D ~/tmp/osec-db ~/tmp/osec | data/osec_reporter Processing /home/legion/tmp/osec ... This is a report generated by osec at 'Fri Oct 4 20:14:00 CEST 2019' Changes in SELINUX policy: - /home/legion/tmp/osec/bash changed policy unconfined_u:object_r:user_tmp_t:s0 -> unconfined_u:object_r:bin_t:s0 Я скопировал обычный /bin/bash в локальную директорию и поменял у него тип и как видите всё видно и выводе утилиты и в отчете. У меня другой результат... [root@homerun ~]# ls -lZ tmp/osec итого 752 -rwxr-xr-x. 1 root root generic_u:object_r:def_t:s2 766656 окт 4 23:18 bash [root@homerun ~]# osec -R -r -D ~/tmp/osec-db ~/tmp/osec Init database for /root/tmp/osec ... /root/tmp/osec stat new uid=root gid=root mode=40755 inode=787427 /root/tmp/osec/bash checksum new checksum=sha1:35db3a8ec7cdea024bc0ab13fe5f6695ab3a7214 /root/tmp/osec/bash stat new uid=root gid=root mode=100755 inode=787428 [root@homerun ~]# osec -R -r -D ~/tmp/osec-db ~/tmp/osec|osec_reporter Init database for /root/tmp/osec ... This is a report generated by osec at 'Fri Oct 4 23:28:59 MSK 2019' No changes [root@homerun ~]# chcon -l s2 tmp/osec/bash [root@homerun ~]# ls -lZ tmp/osec итого 752 -rwxr-xr-x. 1 root root generic_u:object_r:def_t:s2 766656 окт 4 23:18 bash [root@homerun ~]# osec -R -r -D ~/tmp/osec-db ~/tmp/osec|osec_reporter Init database for /root/tmp/osec ... This is a report generated by osec at 'Fri Oct 4 23:29:18 MSK 2019' No changes osec -v | grep ver osec version 1.2.9 [root@homerun ~]# rpm -V osec [root@homerun ~]# И, кстати, хотелось бы чтобы "changed" возникало при любом изменении xattrs, не только при изменении selinux атрибутов. Ясно. $ ldd /usr/bin/osec |grep -c libattr 0 $ ldd src/osec |grep -c libattr 1 У нас osec собран без libattr. (In reply to comment #11) > Ясно. Нет. Дело не в этом. Проблема не в osec. Я всё ещё не могу воспроизвести. Кстати, у меня osec работал когда selinux был выключен (disabled) если это поможет. (In reply to comment #13) > Кстати, у меня osec работал когда selinux был выключен (disabled) > если это поможет. Я пока не знаю, что вам сказать. У меня на Permissive всё работает. При сборке с libattr или без? На установленном Sisyphus? ldd /usr/bin/osec linux-vdso.so.1 (0x00007fff7d1b2000) libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f8119193000) libcdb.so.1 => /usr/lib64/libcdb.so.1 (0x00007f811918d000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f8119185000) libc.so.6 => /lib64/libc.so.6 (0x00007f8118fc7000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f8118fa5000) /lib64/ld-linux-x86-64.so.2 (0x00007f8119323000) (In reply to comment #14) > (In reply to comment #13) > > Кстати, у меня osec работал когда selinux был выключен (disabled) > > если это поможет. > > Я пока не знаю, что вам сказать. > У меня на Permissive всё работает. На disabled может быть другое поведение. (In reply to comment #15) > При сборке с libattr или без? Как выяснилось, эта зависимость паразитная. Она не нужна совсем и не влияет на результат т.к. osec использует системные вызовы напрямую. > На установленном Sisyphus? Я собрал в сизифе osec и проверил его на fedora поскольку у меня сейчас нет ни одной машины с alt + selinux. (In reply to comment #17) > > У меня на Permissive всё работает. > На disabled может быть другое поведение. С чего бы аттибутам вести себя иначе ? Я могу допустить, что при Enforcing у osec не хватает прав читать файлы (это действительно может быть проблемой и нужно написать полиси для osec), но при остальных режимах ... (In reply to comment #18) > (In reply to comment #15) > > При сборке с libattr или без? > > Как выяснилось, эта зависимость паразитная. Она не нужна совсем и не влияет на > результат т.к. osec использует системные вызовы напрямую. > > > На установленном Sisyphus? > > Я собрал в сизифе osec и проверил его на fedora поскольку у меня сейчас нет ни > одной машины с alt + selinux. > > (In reply to comment #17) > > > У меня на Permissive всё работает. > > На disabled может быть другое поведение. > > С чего бы аттибутам вести себя иначе ? > > Я могу допустить, что при Enforcing у osec не хватает прав читать файлы (это > действительно может быть проблемой и нужно написать полиси для osec), но при > остальных режимах ... Кстати (это видно из моего лога) в базу-то она разницу записала! Это видно из сравнения дампов базы. Но сказала почему-то, что изменений нет. Где-то в коде самого osec логика съехала. Может сделаете тестовое задание в сизиф с -O0? (In reply to comment #8) > [root@homerun ~]# chcon -l s2 tmp/osec/bash > [root@homerun ~]# ls -lZ tmp/osec > итого 752 > -rwxr-xr-x. 1 root root generic_u:object_r:def_t:s2 766656 окт 4 23:18 bash Пожалуйста, пришлите мне этот `tmp/osec/bash`. Created attachment 8336 [details]
listxattr.c
Ну или скомпилируйте вот эту утилиту, выполните на `tmp/bash` и приложите сюда вывод.
(In reply to comment #20) > Пожалуйста, пришлите мне этот `tmp/osec/bash`. Глупость. (In reply to comment #8) > [root@homerun ~]# osec -R -r -D ~/tmp/osec-db ~/tmp/osec В порядке бредовой догадки. Покажите пожалуйста результат: find ~/tmp/osec-db -name 'osec.cdb.*' -printf '%f\t' -exec osec-dbversion '{}' \; После drop_privs() список атрибутов уже не читается. Смотрите: (gdb) p listxattr("/bin/tai64nlocal", 0, 0) $2 = 15 (gdb) n 569 drop_privs((user != NULL ? user : def_user), (gdb) n Missing separate debuginfo for /lib64/libnss_sss.so.2 Try to install the hash file /usr/lib/debug/.build-id/93/4021cdcd82f49bef6950213971b1b9cfb1d4bf.debug 572 if (!geteuid()) (gdb) p listxattr("/bin/tai64nlocal", 0, 0) $3 = 0 Нам нужно решить, для чего вообще делать drop_privs и должно ли это приводить к невозможности прочитать атрибуты, если сам файл доступен для чтения. И второй вопрос: как управлять этим через конфигурационный файл? Сейчас osec.cron, который вызывает osec, умеет передавать ему только ограниченный набор аргументов. (Ответ для manowar@altlinux.org на комментарий #24) > После drop_privs() список атрибутов уже не читается. Смотрите: > > (gdb) p listxattr("/bin/tai64nlocal", 0, 0) > $2 = 15 > (gdb) n > 569 drop_privs((user != NULL ? user : def_user), > (gdb) n > Missing separate debuginfo for /lib64/libnss_sss.so.2 > Try to install the hash file > /usr/lib/debug/.build-id/93/4021cdcd82f49bef6950213971b1b9cfb1d4bf.debug > 572 if (!geteuid()) > (gdb) p listxattr("/bin/tai64nlocal", 0, 0) > $3 = 0 > > Нам нужно решить, для чего вообще делать drop_privs и должно ли это > приводить к невозможности прочитать атрибуты, если сам файл доступен для > чтения. Не нужно использовать привилегии которые тебе не нужны. В то время когда это было сделано поддержки аттрибутов не было и привилегий хватало. Сейчас если нужны xattrs нужен CAP_SYS_ADMIN. Это происходит из-за того, что там Trusted extended attributes: Trusted extended attributes are visible and accessible only to processes that have the CAP_SYS_ADMIN capability. Для их чтения нужно использовать osec с опцией --allow-root. > И второй вопрос: как управлять этим через конфигурационный файл? Сейчас > osec.cron, который вызывает osec, умеет передавать ему только ограниченный > набор аргументов. Несложно добавить туда необходимое. (Ответ для Alexey Gladkov на комментарий #25) > Сейчас если нужны xattrs нужен CAP_SYS_ADMIN. Я правильно понимаю, что это такая общая привилегия, которую нельзя выборочно сохранить в drop_privs()? И поэтому нужно вообще отключить drop_privs() передав --allow-root ? > Для их чтения нужно использовать osec с опцией --allow-root. > > > И второй вопрос: как управлять этим через конфигурационный файл? Сейчас > > osec.cron, который вызывает osec, умеет передавать ему только ограниченный > > набор аргументов. > > Несложно добавить туда необходимое. Есть предложение добавить в pipe.conf переменную типа ARGS, через которую можно будет передавать произвольные аргументы. Но могу сделать и отдельную ALLOW_ROOT. (Ответ для manowar@altlinux.org на комментарий #26) > (Ответ для Alexey Gladkov на комментарий #25) > > Сейчас если нужны xattrs нужен CAP_SYS_ADMIN. > > Я правильно понимаю, что это такая общая привилегия, которую нельзя > выборочно сохранить в drop_privs()? И поэтому нужно вообще отключить > drop_privs() передав > --allow-root ? К сожалению да. > > Для их чтения нужно использовать osec с опцией --allow-root. > > > > > И второй вопрос: как управлять этим через конфигурационный файл? Сейчас > > > osec.cron, который вызывает osec, умеет передавать ему только ограниченный > > > набор аргументов. > > > > Несложно добавить туда необходимое. > > Есть предложение добавить в pipe.conf переменную типа ARGS, через которую > можно будет передавать произвольные аргументы. Но могу сделать и отдельную > ALLOW_ROOT. Лучше её назвать PRESERVE_PRIVS (Ответ для Alexey Gladkov на комментарий #27) > Лучше её назвать PRESERVE_PRIVS Вот так: http://git.altlinux.org/people/manowar/packages/?p=osec.git;a=commitdiff;h=160eabce1a3d78582998be331efe02f5169f2b19 ? (Ответ для manowar@altlinux.org на комментарий #28) > (Ответ для Alexey Gladkov на комментарий #27) > > Лучше её назвать PRESERVE_PRIVS > > Вот так: > http://git.altlinux.org/people/manowar/packages/?p=osec.git;a=commitdiff; > h=160eabce1a3d78582998be331efe02f5169f2b19 ? Я забыл написать сюда. Я реализовал уже это в master. Извините. Алексей, рассмотрите ещё вот такой патч? http://git.altlinux.org/people/manowar/packages/?p=osec.git;a=commitdiff;h=7538b4b7b9f74f2020f098ffdb9b465aaec2b078 (Ответ для manowar@altlinux.org на комментарий #30) > Алексей, рассмотрите ещё вот такой патч? > http://git.altlinux.org/people/manowar/packages/?p=osec.git;a=commitdiff; > h=7538b4b7b9f74f2020f098ffdb9b465aaec2b078 В целом неплохой патч. А какое отношение он имеет к этой баге ? Что изменения SELinux атрибутов попадают в общий итог. Я переработал код, который относится к xattrs. Переоткройте, если не исправлено. |