strange audit messages from the dhcpc_t domain

strange audit messages from the dhcpc_t domain

[Paul Krumviede]

i just noticed a few strange denials on a RH 7.2 system running the 
2.4.17-kernel
version. the machine is using DHCP on eth1 and gets assigned an address of
172.16.218.138.

1)	Feb  1 04:02:05 fermat kernel: avc:  denied  { recvfrom } for  pid=2235 
	exe=/usr/sbin/sendmail saddr=0.4.172.16 daddr=218.138.0.0 netif=eth1 
	scontext=system_u:system_r:dhcpc_t
	tcontext=system_u:object_r:netmsg_eth1_t tclass=packet_socket

why is sendmail running in the dhcpc_t domain? and the saddr and daddr 
values look
mangled.

2)	Feb  2 02:37:10 fermat kernel: avc:  denied  { recvfrom } for
	saddr=172.16.218.254 source=17680
	daddr=172.16.218.138 dest=328
	netif=eth1
 	scontext=system_u:system_r:dhcpc_t
	tcontext=system_u:object_r:netmsg_eth1_t tclass=packet_socket

this looks correct, while

3)	Feb  2 02:42:06 fermat kernel: avc:  denied  { recvfrom } for
	saddr=0.8.172.16
	daddr=218.1.0.0
	netif=eth1 scontext=system_u:system_r:dhcpc_t
	tcontext=system_u:object_r:netmsg_eth1_t
	tclass=packet_socket

this also seems to have mangled the saddr/daddr fields (and if i reconstruct
the fields as 172.16.218.1, i don't think that machine would ever emit DHCP
or BOOTP messages, although i could be wrong).

-paul


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: strange audit messages from the dhcpc_t domain

[Stephen Smalley]

On Sat, 2 Feb 2002, Paul Krumviede wrote:

> 1)	Feb  1 04:02:05 fermat kernel: avc:  denied  { recvfrom } for  pid=2235
> 	exe=/usr/sbin/sendmail saddr=0.4.172.16 daddr=218.138.0.0 netif=eth1
> 	scontext=system_u:system_r:dhcpc_t
> 	tcontext=system_u:object_r:netmsg_eth1_t tclass=packet_socket
>
> why is sendmail running in the dhcpc_t domain? and the saddr and daddr
> values look
> mangled.

The recvfrom permission check is performed between the security context of
the receiving socket (inherited by default from the process that created
the socket) and the security context of the packet.  For permission checks
performed during a network input operation, you can't rely on the current
process information (the 'pid' and the 'exe'), because 'current' may be
set to a process that is unrelated to the network operation.  Hence,
sendmail is not running in the dhcpc_t domain; the failure is occurring on
a socket created by dhcpcd due to a lack of this permission in dhcpc.te.
At present, the dhcpc.te file only grants recvfrom permission for eth0,
but you can add permission for eth1 (or, more generally, use the
'netmsg_type' attribute in place of a specific type to grant access to
messages received on any network device).

With regard to the saddr and daddr, this is a bug in the AVC audit code -
it fails to test the skb->protocol field to verify that the protocol is
IP, so it is extracting IP header fields from a packet that may not have
an IP header.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: strange audit messages from the dhcpc_t domain

[Paul Krumviede]

--On Monday, 04 February, 2002 10:07 -0500 Stephen Smalley 
<sds@tislabs.com> wrote:

>
> On Sat, 2 Feb 2002, Paul Krumviede wrote:
>
>> 1)	Feb  1 04:02:05 fermat kernel: avc:  denied  { recvfrom } for
>> pid=2235 exe=/usr/sbin/sendmail saddr=0.4.172.16 daddr=218.138.0.0
>> 	netif=eth1 scontext=system_u:system_r:dhcpc_t
>> 	tcontext=system_u:object_r:netmsg_eth1_t tclass=packet_socket
>>
>> why is sendmail running in the dhcpc_t domain? and the saddr and daddr
>> values look
>> mangled.
>
> The recvfrom permission check is performed between the security context of
> the receiving socket (inherited by default from the process that created
> the socket) and the security context of the packet.  For permission checks
> performed during a network input operation, you can't rely on the current
> process information (the 'pid' and the 'exe'), because 'current' may be
> set to a process that is unrelated to the network operation.  Hence,
> sendmail is not running in the dhcpc_t domain; the failure is occurring on
> a socket created by dhcpcd due to a lack of this permission in dhcpc.te.

OK. i had been assuming that the permission check was finding the
process owning the socket to which the packet is destined, but that
seems to be incorrect.

> At present, the dhcpc.te file only grants recvfrom permission for eth0,
> but you can add permission for eth1 (or, more generally, use the
> 'netmsg_type' attribute in place of a specific type to grant access to
> messages received on any network device).

i was reluctant to grant this permission until i knew why i was seeing
such messages.

> With regard to the saddr and daddr, this is a bug in the AVC audit code -
> it fails to test the skb->protocol field to verify that the protocol is
> IP, so it is extracting IP header fields from a packet that may not have
> an IP header.

i was wondering if it might have been an off-by-2 error, as an address
matching legitimate addresses on the subnet in question seemed to be
split across the saddr and daddr fields.

thanks,
-paul


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.