On Jun 21, 2006, at 10:56 AM, Venkat Yekkirala wrote:
It seems like semantics of the flow sid is different between output
and input. On output, it's based on the socket and on input it's
based on the sa. The flow/sa analogy makes sense to me, but the
socket less so (multiple sockets can use the same flow).
Different flows (as opposed to sockets) may use the same
flow cache
entry.
Is that what you meant here?
No. I meant that the flow's sid is computed from the socket on
output and the sa on input. These would seem to have different
authorization requirements to me (socket requires permission to send
on output and sa should match policy on input). Does that
make sense
or should I try to be more specific?
The cache uses these sid's subsequently of course, but we authorize
socket to sa on input and flow (which is derived from socket) to sa
on output.
Let's take an example.
Given that you have the following in the xfrm policy:
xfrm_policy ftpd_xfrm_t
xfrm_state ftpd_sa_t (optionally can be negotiated via IKE, in
which case
it would use ftpd_xfrm_t as the type for the negotiated SA).
This is how SELinux policy would look like:
For output:
allow ftpd_t ftpd_xfrm_t:association { polmatch };
allow ftpd_t ftpd_sa_t:association { sendto };
allow ftpd_sa_t ftpd_xfrm_t:association { polmatch };
So, the socket's type need not match the policy's type or the sa's
type (nor does the sa's type have to match the policy's type) as long
as the subjects in this have 'polmatch' access.
So, the answer to the question below is 'yes, if polmatch permission
from sock type to policy'
Question: if the sock type does not match the policy type
(xfrm_lookup hook on output
step (2)), can we send the packet?
This was my concern, so this resolves the problem although the
operation polmatch is a bit non-intuitive.
Should we use another term? ('use' 'apply' -- poluse doesn't sound so
good) Is there a precedent for this type of operation in SELinux?
For input:
allow ftpd_sa_t ftpd_xfrm_t:association { polmatch }; (ALREADY
ALLOWED PER
OUTPUT POLICY)
allow ftpd_t ftpd_sa_t:association { recvfrom };
This makes sense.
If you are wondering about the asymmetry in the number of access
checks, it
is because in the output case there's the extra step of selecting
SAs given
a xfrm policy rule and a flow/socket, whereas in the input case the
SAs are
already tied to the flow. This assymetry is thus inherent.
Yes, I understand this, and agree with this approach.
Regards,
Trent.
----------------------------------------------
Trent Jaeger, Associate Professor
Pennsylvania State University, CSE Dept
346A IST Bldg, University Park, PA 16802
Email: [EMAIL PROTECTED]
Ph: (814) 865-1042, Fax: (814) 865-3176
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
