On Thursday, December 19, 2013 12:48:40 PM Andy Ruch wrote:
> I considered what you said about the capability not being
> available to restrict the AF_PACKET traffic on a per interface basis. It led
> me to investigate my selinux policy further beyond just my application. I
> saw that several applications had the ability to use AF_PACKET sockets,
> including applications like virtd, xen, dnsmasq, ping, traceroute, and
> more. My system also runs virtual machines so I grew more concerned that
> I’m not able to restrict virtd’s network access if it were compromised.
>
> You described the fix as adding a new LSM hook and SELinux glue. How
> difficult would this be to add?
Off the top of my head, it would require the following at a minimum:
* LSM hooks in the AF_PACKET code to perform access control before the packet
is handed off to the network device layer, see "net/packet/af_packet.c".
* SELinux/LSM glue code to implement the SELinux access controls for the
outbound AF_PACKET traffic, see "selinux_ip_postroute()". I think the only
outbound access control that makes sense in this case would be the
netif:egress control, although there may be some use for secmark, I just
haven't thought much about secmark in a non-IP case.
* Check to ensure that inbound AF_PACKET traffic ends up going through the
socket filter code and hitting the security_sock_rcv_skb() LSM hook, if not,
an additional LSM hook would be needed in the AF_PACKET code to deal with
inbound traffic.
* SELinux/LSM glue code to implement the SELinux access controls for the
outbound AF_PACKET traffic, see "selinux_socket_sock_rcv_skb()". Similar to
the outbound access control, I believe netif:ingress is the key control with a
possibility for secmark as well.
* Add a new SELinux policy capability ("selinux_policycap_packet"?) to
enable/disable all of the new controls listed above.
Policy wise, I don't think there would be any extra work required as we would
be reusing the existing network ingress/egress controls and doing so in such a
way that preserves their intent. If anything, I think the changes would be
more in line with what the policy author originally intended.
I'm somewhat interested in this now, if you're not going to follow-up on this
with any patches please let me know and I'll toss is on my todo pile, but be
warned, the pile is tall and gets taller with each passing day :)
> And if it was fixed, what would be the process for getting it released into
> RHEL 6?
That is something that is best discussed with your RH support contact and not
with the SELinux community at large. Feel free to contact me off list if
needed.
--
paul moore
security and virtualization @ redhat
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
