On 08/18/2010 05:13 PM, Daniel Fazekas wrote:
On Aug 18, 2010, at 17:01, Daniel B. Thurman wrote:
>>> node=(removed) type=AVC msg=audit(1282086325.907:81309): avc: denied
{name_bind } for pid=23536 comm="spamassassin" src=32726
scontext=system_u:system_r:spamc_t:s0
>>> tcontext=system_u:object_r:port_t:s0 tclass=udp_socket
>> It kind of depends in my view. Here the spamassassin client app tries to bind udp
socket to port 32726.
I think it's a mistake to have the same limitations apply to both /usr/bin/spamc and
/usr/bin/spamassassin, if that is really the case with the current policy.
ls -Z /usr/bin/spam*
-rwxr-xr-x. root root system_u:object_r:spamc_exec_t:s0 /usr/bin/spamassassin
-rwxr-xr-x. root root system_u:object_r:spamc_exec_t:s0 /usr/bin/spamc
-rwxr-xr-x. root root system_u:object_r:spamd_exec_t:s0 /usr/bin/spamd
/usr/bin/spamassassin is the all-in-one standalone version. It is normal for it to
network freely and would need to have the permissions of both spamd and spamc combined.
/usr/bin/spamc on the other hand only needs to talk to spamd running on localhost tcp
port 783 and nothing else, and spamd does all the real work.
For what it's worth, I use spamd/spamc and didn't have any issues with anything
being denied in many, many years.
Something weird going on in policy:
typealias spamc_exec_t alias spamassassin_exec_t;
typealias spamc_t alias spamassassin_t;
corenet_udp_bind_generic_node(spamassassin_t)
corenet_udp_bind_generic_port(spamassassin_t)
corenet_sendrecv_generic_server_packets(spamassassin_t)
corenet_dontaudit_udp_bind_all_ports(spamassassin_t)
So spamc_t is an alias to spamassassin_t in fedora. in theory that would
give spamc_t access to bind udp sockets to generic ports as spamassassin
is allowed this access.
Looks like fedora doesnt differentiate between spamc and spamassassin,
but somehow that does not work.
--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux