1) собрать базу osec (osec-1.2.9-alt1.x86_64) в которой есть файл c selinux атрибутами 2) поменять атрибут файла chcon -l s2 somefile 3) проверить статус oseс - выдаст отсутствие изменений. В базе в xattr изменения присутствуют setenforce все равно какой - permissive, enforcing.
как вы проверяет статус 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. Переоткройте, если не исправлено.
