Clamav/SeLinux, issue with system call recvmsg, and auxilary data.

Dominick Grift domg472 at gmail.com
Tue Sep 29 21:27:54 UTC 2009


On Tue, Sep 29, 2009 at 06:53:21PM +0100, J. David Rye of Roadtech wrote:
> 
> 
> 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 at 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

My guess is that one of these create the initrc_tmp_t object. 

It would be best to get rid of all the initrc_t processes by writing policy for the milters and nagios

initrc_t is a unconfined domain, a weak spot in your configuration.

but as a temporary "as long as it works" fix you could run the avc denial throught audit2allow -M and load the module with semodule -i. until you fixed the core issue of your initrc_t processes.

I might be able to help write policy for the milters but i would need a rpm -ql of the package and i wouldnt be able to test policy myself so youd have to test it and provide feedback. Might take a while..



 myclamd.
> myclamd.fc  myclamd.if  myclamd.pp  myclamd.te
> [root at 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 at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20090929/93c06c29/attachment.sig>


More information about the fedora-selinux-list mailing list