Spamassassin emails have wrong perms -- CC'ed to selinux list
Justin Willmert
justin at jdjlab.com
Wed Feb 1 22:18:57 UTC 2006
Daniel J Walsh wrote:
> Richard E Miles wrote:
>> On Sun, 29 Jan 2006 22:53:25 -0600
>> Justin Willmert <justin at jdjlab.com> wrote:
>>
>>
>>> Ivan Gyurdiev wrote:
>>>
>>>>> I'm cc-ing this to the fedora-selinux-list. I think some of the
>>>>> problems may be applicable there.
>>>>>
>>>>> OK, after some more testing, when I disable SELinux, many of the
>>>>> errors go away. First of all, I get rid of the error message
>>>>> saying user can not be found and with it the 'still running as
>>>>> root' error. Second, it is able to access the bayes_journal file
>>>>> (as long as normal unix permissions are right, which I've figured
>>>>> out). So I guess the problem is an SELinux issue which I can't
>>>>> solve. I'd attach some avc error messages, but I can't seem to
>>>>> find any. I've looked in maillog, secure, and messages, but nothing.
>>>>>
>>>> Have you looked in the audit log, where all such messages are
>>>> usually found ?
>>>> /var/log/audit.log
>>>>
>>>>
>>> Below is what showed up in audit/audit.log when I sent a message
>>> through
>>> spamassassin. I'm _*really*_ rusty on SELinux...it's the one thing I
>>> have to deal with quite often that I haven't been able to learn how to
>>> use...it's so foreign to me. I've never looked in audit.log before: the
>>> avc messages used to show up in messages, but now as far back as my
>>> logs
>>> go, I don't have a single avc message. This all looks like jibberish to
>>> me, so I need your guy's help.
>>>
>>> Thanks,
>>> Justin
>>>
>>> type=AVC msg=audit(1138596151.681:104174): avc: denied {
>>> name_connect } for pid=23796 comm="spamd" dest=389
>>> scontext=root:system_r:spamd_t
>>> tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket
>>> type=SYSCALL msg=audit(1138596151.681:104174): arch=40000003
>>> syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7
>>> items=0 pid=23796 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
>>> sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl"
>>> type=SOCKADDR msg=audit(1138596151.681:104174):
>>> saddr=02000185C0A801940000000000000000
>>> type=SOCKETCALL msg=audit(1138596151.681:104174): nargs=3 a0=7
>>> a1=9b1fe80 a2=10
>>> type=AVC msg=audit(1138596153.220:104175): avc: denied {
>>> name_connect } for pid=23796 comm="spamd" dest=389
>>> scontext=root:system_r:spamd_t
>>> tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket
>>> type=SYSCALL msg=audit(1138596153.220:104175): arch=40000003
>>> syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7
>>> items=0 pid=23796 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99
>>> egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl"
>>> type=SOCKADDR msg=audit(1138596153.220:104175):
>>> saddr=02000185C0A801940000000000000000
>>> type=SOCKETCALL msg=audit(1138596153.220:104175): nargs=3 a0=7
>>> a1=9b6a6f0 a2=10
>>> type=AVC msg=audit(1138596160.388:104176): avc: denied {
>>> name_connect } for pid=23797 comm="spamd" dest=389
>>> scontext=root:system_r:spamd_t
>>> tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket
>>> type=SYSCALL msg=audit(1138596160.388:104176): arch=40000003
>>> syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7
>>> items=0 pid=23797 auid=600 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
>>> sgid=0 fsgid=0 comm="spamd" exe="/usr/bin/perl"
>>> type=SOCKADDR msg=audit(1138596160.388:104176):
>>> saddr=02000185C0A801940000000000000000
>>> type=SOCKETCALL msg=audit(1138596160.388:104176): nargs=3 a0=7
>>> a1=9b20050 a2=10
>>> type=AVC msg=audit(1138596164.032:104177): avc: denied {
>>> name_connect } for pid=23797 comm="spamd" dest=389
>>> scontext=root:system_r:spamd_t
>>> tcontext=system_u:object_r:ldap_port_t tclass=tcp_socket
>>> type=SYSCALL msg=audit(1138596164.032:104177): arch=40000003
>>> syscall=102 success=no exit=-13 a0=3 a1=bfb2dc20 a2=1229cb8 a3=7
>>> items=0 pid=23797 auid=600 uid=0 gid=0 euid=99 suid=0 fsuid=99
>>> egid=99 sgid=0 fsgid=99 comm="spamd" exe="/usr/bin/perl"
>>> type=SOCKADDR msg=audit(1138596164.032:104177):
>>> saddr=02000185C0A801940000000000000000
>>> type=SOCKETCALL msg=audit(1138596164.032:104177): nargs=3 a0=7
>>> a1=9b84af0 a2=10
>>>
>>>
>> I get these also on my system. So you're not the only one. Is there a
>> fix for this?
>>
>>
> Ok I have placed an updated version of policy on my people page. It
> will be in rawhide tonight.
>
> ftp://people.redhat.com/dwalsh/SELinux/Fedora
>
> But you can solve these problems yourself by using audit2allow and
> loadable modules.
>
> If you ran
>
audit2allow -M gives me:
unknown option, '-M'
audit2allow [-d] [-v] [-l] [-i <inputfile> ] [-o <outputfile>]
-d read input from output of /bin/dmesg
-v verbose output
-l read input only after last "load_policy"
-i read input from <inputfile>
-o append output to <outputfile>
Are modules only a function in FC5test2 right now (I'm running FC4 just
in case you didn't know that)?
> audit2allow -M spamd /var/log/audit/audit.log
>
> You would have seen something like this.
>
>> audit2allow -M spamd -i /var/log/audit/audit.log
>> Generating type enforcment file: spamd.te
>> Compiling policy: checkmodule -M -m -o spamd.mod spamd.te
>> semodule_package -o spamd.pp -m spamd.mod
>> Building package: semodule_package -o spamd.pp -m spamd.mod
>>
>> ******************** IMPORTANT ***********************
>>
>> In order to load this newly created policy package into the kernel,
>> you are required to execute
>>
>> semodule -i spamd.pp
> If you then ran the semodue -i spamd.pp
>
I don't have a semodule program (either in path or with a search of all
files)
> it should fix your problem.
>
> This is the te file that audit2allow created
>> module spamd 1.0;
>>
>> require {
>> role object_r;
>> role system_r;
>>
>> class tcp_socket name_connect;
>>
>> type ldap_port_t;
>> type spamd_t;
>> };
>>
>>
>> allow spamd_t ldap_port_t:tcp_socket name_connect;
>>
> When policy gets updated with your fix, you could remove this loadable
> module with the command
> semodule -r slapd
>
> semodule -l
>
> will list all of your loadable modules.
Same problem as above.
Thanks for the help, Dan. I guess I'll just wait until the next policy
release. I'll make sure to remember the commands for when I do go to FC5
and can use these. I still have problems with dovecot and selinux (right
now I have a boolean set unenforcing dovecot. I've never dug far enough
to make a bug report worthwhile. It's probably half my fault anyway) and
it would have been a lot of help for other things I've had to work around.
Thanks for the help,
Justin
More information about the fedora-list
mailing list