Hello All I triggered this issue with clamav/clamav-milter 0.95.2 from rpmforge running on a test box with Centos 5.3 Clamd opens a socket /var/run/clamav/clamd.sock to accept requests to scan things. ls -Z /var/run/clamav/clamd.sock srwxrwxrwx clamav clamav root:object_r:clamd_var_run_t /var/run/clamav/clamd.sock Requests are read using the system call recvmsg, this allows for the passing auxiliary control data. Clamav-milter 0.95.2 uses this to pass a handle to the temp file containing the data to be scanned With SeLinux set to targeted enforcing, this call reads and returns the normal data fine, but returns with the flag MSG_CTRUNC set. according to the man page this is "indicates that some control data were discarded due to lack of space in the buffer for ancillary data." clamd responded by closing the socket, clamav-milter responded to the closed socket by looping a 100% CPU. :-( Running the audit log through audit2allow suggests grep clam /var/log/audit/audit.log | audit2allow -m local > local.te [root@fallback0 selinux]# cat local.te module local 1.0; require { type initrc_tmp_t; type proc_t; type sysctl_kernel_t; type clamd_t; class dir search; class file { read write getattr }; } #============= clamd_t ============== allow clamd_t initrc_tmp_t:file { read write getattr }; allow clamd_t proc_t:file { read getattr }; allow clamd_t sysctl_kernel_t:dir search; allow clamd_t sysctl_kernel_t:file read;

The allow clamd_t proc_t:file { read getattr }; looks to relate to reading /proc/meminfo allow clamd_t sysctl_kernel_t:dir search; allow clamd_t sysctl_kernel_t:file read; Look to relate to these log entries type=AVC msg=audit(1254139856.343:48724): avc: denied { search } for pid=14771 comm="clamd" name="kernel" dev=proc ino=-268435416 scontext=root:system_r:clamd_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir type=AVC msg=audit(1254139856.343:48724): avc: denied { read } for pid=14771 comm="clamd" name="ngroups_max" dev=proc ino=-268435368 scontext=root:system_r:clamd_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file type=AVC msg=audit(1254149740.665:48885): avc: denied { search } for pid=1261 comm="clamd" name="kernel" dev=proc ino=-268435416 scontext=root:system_r:clamd_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir This if I have figured it out right relate to something that clamd is calling in turn trying to read /proc/sys/kernel/ngroups_max So by elimination allow clamd_t initrc_tmp_t:file { read write getattr }; Must relate to the the use of auxiliary data with the socket, and the following log entries but I do not see why. Can anyone explain? type=AVC msg=audit(1254150147.188:48924): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D3063666237656532666331656139656636323364373463316236626532623735202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=AVC msg=audit(1254150153.681:48925): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D3336316332323033323138613239633865363633633937303962663133363664202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=AVC msg=audit(1254150177.903:48926): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D3366636162623138633237636231383466643064656630643838353063363933202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=AVC msg=audit(1254150188.366:48927): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D6366393131623632353130333564353832656435396466663136373362626131202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=AVC msg=audit(1254150220.428:48928): avc: denied { read write } for pid=1288 comm="clamd" path=2F746D702F636C616D61762D3931633534623761393630653531386630363539653033363537303937323135202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file Yours J. David Rye ************************************************************************* This e-mail is confidential and may be legally privileged. It is intended solely for the use of the individual(s) to whom it is addressed. Any content in this message is not necessarily a view or statement from Road Tech Computer Systems Limited but is that of the individual sender. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. We use reasonable endeavours to virus scan all e-mails leaving the company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our networks is reserved by us Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 Registered in England No: 02017435, Registered Address: Charter Court, Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. ************************************************************************* -- fedora-selinux-list mailing list fedora-selinux-list(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list

On Monday 28 September 2009 16:49, Dominick Grift wrote: > On Mon, Sep 28, 2009 at 04:22:18PM +0100, J. David Rye of Roadtech wrote: > > Hello All > > > > I triggered this issue with clamav/clamav-milter 0.95.2 from rpmforge > > running on a test box with Centos 5.3 > > > > Clamd opens a socket /var/run/clamav/clamd.sock to accept requests to > > scan things. > > > > ls -Z /var/run/clamav/clamd.sock > > srwxrwxrwx clamav clamav root:object_r:clamd_var_run_t > > /var/run/clamav/clamd.sock > > > > Requests are read using the system call recvmsg, this allows for the > > passing auxiliary control data. > > > > Clamav-milter 0.95.2 uses this to pass a handle to the temp file > > containing the data to be scanned > > > > With SeLinux set to targeted enforcing, this call reads and returns the > > normal data fine, but returns with the flag MSG_CTRUNC set. > > > > according to the man page this is > > "indicates that some control data were discarded due to lack of space in > > the buffer for ancillary data." > > > > clamd responded by closing the socket, clamav-milter responded to the > > closed socket by looping a 100% CPU. :-( > > > > > > Running the audit log through audit2allow suggests > > > > grep clam /var/log/audit/audit.log | audit2allow -m local > local.te > > [root@fallback0 selinux]# cat local.te > > > > module local 1.0; > > > > require { > > type initrc_tmp_t; > > type proc_t; > > type sysctl_kernel_t; > > type clamd_t; > > class dir search; > > class file { read write getattr }; > > } > > > > #============= clamd_t ============== > > allow clamd_t initrc_tmp_t:file { read write getattr }; > > allow clamd_t proc_t:file { read getattr }; > > allow clamd_t sysctl_kernel_t:dir search; > > allow clamd_t sysctl_kernel_t:file read; > > The first line means that something runs in the initrc_t init script > domain. Either the program executable file for this process is mislabeled > or there is no policy for this init daemon. > > ps auxZ | grep initrc_t > > The second and third / > fourth line signal that clamd_t needs read access to read_system_state > and read_sysctls. > > You could extend the clamd domain with a custom policy module to implement > this > > echo "policy_module(myclamd, 0.0.1)" >> myclamd.te; > echo "require { type clamd_t; }" > myclamd.te; > echo "kernel_read_system_state(clamd_t)" > myclamd.te; > echo "kernel_read_kernel_sysctls(clamd_t)" > myclamd.te; > > make -f /usr/share/selinux/devel/Makefile myclamd.pp > sudo semodule -i myclamd.pp > Thank you setsebool clamd_disable_trans=0 service clamd restart ls -Z /usr/sbin/clamav-milter /usr/sbin/clamd -rwxr-xr-x root root system_u:object_r:sbin_t /usr/sbin/clamav-milter -rwxr-xr-x root root system_u:object_r:clamd_exec_t /usr/sbin/clamd ps auxZ | egrep "initrc_t|clam" system_u:system_r:initrc_t nagios 2213 0.0 0.0 4968 948 ? Ss Sep23 0:12 nrpe -c /etc/nagios/nrpe.cfg -d system_u:system_r:initrc_t milter 2326 0.1 0.4 191796 4212 ? Ssl Sep23 13:26 /usr/local/sbin/milter-ahead root:system_r:clamd_t clamav 3227 1.1 7.4 88088 75092 ? Ssl 17:58 0:08 clamd root:system_r:unconfined_t:SystemLow-SystemHigh root 12979 0.0 0.0 3912 692 pts/0 R+ 18:10 0:00 egrep initrc_t|clam root:system_r:initrc_t clamav 20469 0.2 0.1 197700 1056 ? Ssl Sep25 12:29 clamav-milter --config-file=/etc/clamav-milter.conf

myclamd.fc myclamd.if myclamd.pp myclamd.te [root@fallback0 selinux]# cat myclamd.te policy_module(myclamd, 0.0.1) require { type clamd_t; } kernel_read_system_state(clamd_t) kernel_read_kernel_sysctls(clamd_t) make -f /usr/share/selinux/devel/Makefile myclamd.pp semodule -i myclamd.pp service clamd stop service clamav-milter stop /bin/rm /var/log/audit/audit* service auditd restart service clamd start service clamav-milter start # Now wait a bit grep clam /var/log/audit/audit.log | audit2allow -m local > local.te cat local.te module local 1.0; require { type initrc_tmp_t; type clamd_t; class file { read write }; } #============= clamd_t ============== grep clam /var/log/audit/audit.log | head type=AVC msg=audit(1254244568.860:58679): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3538623532393261306361353666363733383634343663306531633261303834202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1254244568.860:58679): arch=40000003 syscall=102 success=yes exit=9 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) type=AVC msg=audit(1254244587.836:58680): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3738373964653632626161306635396234646433626264613738376565363134202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1254244587.836:58680): arch=40000003 syscall=102 success=yes exit=9 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) type=AVC msg=audit(1254244625.080:58681): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3838636236663661333332643165336262376563353861633537303764343966202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1254244625.080:58681): arch=40000003 syscall=102 success=yes exit=9 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) type=AVC msg=audit(1254244637.887:58682): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3664613038663635306539396134396638376331363361373661323636633030202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1254244637.887:58682): arch=40000003 syscall=102 success=yes exit=9 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) type=AVC msg=audit(1254244638.164:58683): avc: denied { read write } for pid=14527 comm="clamd" path=2F746D702F636C616D61762D3830373639613532393465313533656333313966626638393963333863616231202864656C6574656429 dev=dm-0 ino=34668546 scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1254244638.164:58683): arch=40000003 syscall=102 success=yes exit=1 a0=11 a1=bfbe3610 a2=97763d4 a3=0 items=0 ppid=1 pid=14527 auid=0 uid=100 gid=101 euid=100 suid=100 fsuid=100 egid=101 sgid=101 fsgid=101 tty=(none) ses=2 comm="clamd" exe="/usr/sbin/clamd" subj=root:system_r:clamd_t:s0 key=(null) Which is that auxiliary data transfer with recvmsg failing on the socket the clamd created in the first place. ls -Z /var/run/clamav/clamd.sock srwxrwxrwx clamav clamav root:object_r:clamd_var_run_t /var/run/clamav/clamd.sock Why does the normal data stream through the socket work fine, but transferring file handles fail? > > The allow clamd_t proc_t:file { read getattr }; looks to relate to > > reading /proc/meminfo > > > > allow clamd_t sysctl_kernel_t:dir search; > > allow clamd_t sysctl_kernel_t:file read; > > Look to relate to these log entries > > type=AVC msg=audit(1254139856.343:48724): avc: denied { search } for > > pid=14771 comm="clamd" name="kernel" dev=proc ino=-268435416 > > scontext=root:system_r:clamd_t:s0 > > tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir type=AVC > > msg=audit(1254139856.343:48724): avc: denied { read } for pid=14771 > > comm="clamd" name="ngroups_max" dev=proc ino=-268435368 > > scontext=root:system_r:clamd_t:s0 > > tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file type=AVC > > msg=audit(1254149740.665:48885): avc: denied { search } for pid=1261 > > comm="clamd" name="kernel" dev=proc ino=-268435416 > > scontext=root:system_r:clamd_t:s0 > > tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir > > > > This if I have figured it out right relate to something that clamd is > > calling in turn trying to read /proc/sys/kernel/ngroups_max > > > > > > So by elimination > > allow clamd_t initrc_tmp_t:file { read write getattr }; > > > > Must relate to the the use of auxiliary data with the socket, and the > > following log entries but I do not see why. Can anyone explain? > > > > type=AVC msg=audit(1254150147.188:48924): avc: denied { read write } > > for pid=1288 comm="clamd" > > path=2F746D702F636C616D61762D30636662376565326663316561396566363233643734 > >63316236626532623735202864656C6574656429 dev=dm-0 ino=34668546 > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > tclass=file type=AVC msg=audit(1254150153.681:48925): avc: denied { > > read write } for pid=1288 comm="clamd" > > path=2F746D702F636C616D61762D33363163323230333231386132396338653636336339 > >37303962663133363664202864656C6574656429 dev=dm-0 ino=34668546 > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > tclass=file type=AVC msg=audit(1254150177.903:48926): avc: denied { > > read write } for pid=1288 comm="clamd" > > path=2F746D702F636C616D61762D33666361626231386332376362313834666430646566 > >30643838353063363933202864656C6574656429 dev=dm-0 ino=34668546 > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > tclass=file type=AVC msg=audit(1254150188.366:48927): avc: denied { > > read write } for pid=1288 comm="clamd" > > path=2F746D702F636C616D61762D63663931316236323531303335643538326564353964 > >66663136373362626131202864656C6574656429 dev=dm-0 ino=34668546 > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > tclass=file type=AVC msg=audit(1254150220.428:48928): avc: denied { > > read write } for pid=1288 comm="clamd" > > path=2F746D702F636C616D61762D39316335346237613936306535313866303635396530 > >33363537303937323135202864656C6574656429 dev=dm-0 ino=34668546 > > scontext=root:system_r:clamd_t:s0 tcontext=root:object_r:initrc_tmp_t:s0 > > tclass=file > > > > > > Yours > > > > J. David Rye > > > > > > > > > > > > > > > > > > > > > > > > ************************************************************************* > > This e-mail is confidential and may be legally privileged. It is intended > > solely for the use of the individual(s) to whom it is addressed. Any > > content in this message is not necessarily a view or statement from Road > > Tech Computer Systems Limited but is that of the individual sender. If > > you are not the intended recipient, be advised that you have received > > this e-mail in error and that any use, dissemination, forwarding, > > printing, or copying of this e-mail is strictly prohibited. We use > > reasonable endeavours to virus scan all e-mails leaving the company but > > no warranty is given that this e-mail and any attachments are virus free. > > You should undertake your own virus checking. The right to monitor e-mail > > communications through our networks is reserved by us > > > > Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, > > Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 > > Registered in England No: 02017435, Registered Address: Charter Court, > > Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. > > ************************************************************************* > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list(a)redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list ************************************************************************* This e-mail is confidential and may be legally privileged. It is intended solely for the use of the individual(s) to whom it is addressed. Any content in this message is not necessarily a view or statement from Road Tech Computer Systems Limited but is that of the individual sender. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. We use reasonable endeavours to virus scan all e-mails leaving the company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our networks is reserved by us Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley, Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17 Registered in England No: 02017435, Registered Address: Charter Court, Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE. ************************************************************************* -- fedora-selinux-list mailing list fedora-selinux-list(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list