Hi, we've seen SELinux reports from our users that dovecot tried to use something that needs CAP_NET_ADMIN capability. Before enabling it, we would like to know where it originated from. I've checked the sources, but was not able to find anything that would require this capability. Do you know for what it is used? CAP_NET_ADMIN Perform various network-related operations: * interface configuration; * administration of IP firewall, masquerading, and accounting; * modify routing tables; * bind to any address for transparent proxying "IP_TRANSPARENT"; * set type-of-service (TOS) "IP_TOS" * clear driver statistics; * set promiscuous mode; * enabling multicasting; * use setsockopt(2) to set the following socket options: SO_DEBUG, SO_MARK, SO_PRIORITY (for a priority outside the range 0 to 6),SO_RCVBUFFORCE, and SO_SNDBUFFORCE Cheers, Michal Hlavinka
On 20 Jun 2017, at 14.18, Michal Hlavinka <mhlavink at redhat.com> wrote:> > Hi, > > we've seen SELinux reports from our users that dovecot tried to use something that needs CAP_NET_ADMIN capability. Before enabling it, we would like to know where it originated from. I've checked the sources, but was not able to find anything that would require this capability. Do you know for what it is used?Is this something that changed recently? Anyway, no idea. Do they have any more details, like is it even the dovecot master process that causes it? Or does it say which syscall fails?> CAP_NET_ADMIN > Perform various network-related operations: > * interface configuration; > * administration of IP firewall, masquerading, and accounting; > * modify routing tables; > * bind to any address for transparent proxying "IP_TRANSPARENT"; > * set type-of-service (TOS) "IP_TOS" > * clear driver statistics; > * set promiscuous mode; > * enabling multicasting; > * use setsockopt(2) to set the following socket options: SO_DEBUG, SO_MARK, SO_PRIORITY (for a priority outside the range 0 to 6),SO_RCVBUFFORCE, and SO_SNDBUFFORCENone of these.
>> we've seen SELinux reports from our users that dovecot tried to use something that needs CAP_NET_ADMIN capability. Before enabling it, we would like to know where it originated from. I've checked the sources, but was not able to find anything that would require this capability. Do you know for what it is used? > > Is this something that changed recently? Anyway, no idea. Do they have any more details, like is it even the dovecot master process that causes it? Or does it say which syscall fails?Thanks for the answer. We've looked into this a little bit more and found out that this message is caused by what happens in kernel (and network configuration). It is not caused by what dovecot does. Cheers, Michal