Traditionally we have always checked a packet's secmark label against the
receiving socket and granted access based on allow rules similar to the one
below:
allow socket_t secmark_t:packet recv;
... we performed a similar check when sending packets:
allow socket_t secmark_t:packet send;
However, when we are dealing with forwarded traffic we do not have a sending
or receiving socket to compare the packet's secmark label against to perform
access control. Despite the lack of a socket, I believe we can still provide
useful access control with secmark labels by using the packet's peer label
(quick refresher, the packet's peer label is taken/derived from the original
sending socket and "attached" to the packet via NetLabel or labeled IPsec).
Since the packet's peer label conveys the same label as the sending socket,
using the packet's peer label in place of the sending socket seems to be a
natural fit.
Agree? Disagree? Other ideas?
Working under the assumption that you all agree, do you think we should stick
with the existing "packet { send recv }" permissions for forwarded traffic?
The "send" permission still makes sense to me for outgoing forwarded traffic
but the "recv" permission is all wrong since the forwarding host isn't
consuming the packet like it is with the existing "recv" permission. With
that in mind, I'd suggest adding a new permission, "forward", which is used
when checking inbound forwarded traffic.
Agree? Disagree? Other ideas?
So, in summary, here are the SECMARK permission checks applied to locally
generated or consumed traffic [this is the status quo]:
# inbound traffic
allow socket_t secmark_t:packet recv;
# outbound traffic
allow socket_t secmark_t:packet send;
... and these are the proposed SECMARK permission checks applied to forwarded
traffic as it enters and exists the forwarding-host/router:
# inbound traffic to be forwarded
allow peer_t secmark_t:packet forward;
# outbound forwarded traffic
allow peer_t secmark_t:packet send;
--
paul moore
linux security @ hp
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
