some things to discuss about MAC

[Ilmar S. Habibulin]

On Fri, 28 Dec 2001, Robert Watson wrote:

> My temptation would be instead to process based on the mbuf MAC label, and
> simply make sure CIPSO processing happened before the packets were fed
> into ipfw.  This would mean we could process packets not using CIPSO, and
ipfw deals with ip packet header only. and parses it independently from
ip_dooptions(m), which i use to label mbuf with packet label, if it
exists. So we can teach ipfirewall to parse, understand and make access
control decision based on CIPSO, because CIPSO is one of the IP packet
header options. nothing more from ipfw point of view.

> avoid modifying packets without CIPSO (such as those popping out of an
> IPsec tunnel with an assigned label) in order to allow them to be
> processed.  That doesn't mean we shouldn't also support filtering based on
> CIPSO, but this route might be simpler.
So there would be no packet modifications, because ipfw didn't deal with
mbuf of the packet. It would not assign any label on mbuf. It would only
check existence of CIPSO, parse it, if exists, and match the rule.
That's my proposal.

> Filtering based on IP using this type of filtering sounds relatively
> straight forward -- however, things are slightly more complex for
> filtering based on (say) UDP port number, because UDP errors are reported
> out of band using ICMP, making them harder to match.
Well, maybe i'm looking at this problem in a more simple way. I think,
that if we decide to implement such functionality, then the first step
maybe implementing simple cipso based filter. As i understand you are
talking about dynamic rules? I haven't looked at them yet, so can't say
anything.

> I'm actually running into an interesting problem involving TCP right now.
> Currently, I don't polyinstantiate the port space, I just do access
> control.  When a TCP response is sent to a packet, and there's an
> associated socket, the socket's label is used for the response packet.
You are using the label of associated socket even if it is a negative
reply (RST)?

> However, when there's no socket, the original query's label is used.  The
> result is that if a port is accepting connections, but the socket is
> labeled such that you are not permitted to talk to it, you get a
> connection timed out.  But if you try to connect to a port that is not
Well, then use the querys' label for outgoing packet when access is
denied.

> open (unless interface rules restrict it) you get the connection refused
> RST.  Not a huge problem but something to resolve at some point.  The good
> news is that access control on raw sockets, UDP sockets, and TCP sockets
> all now appears to be working correctly (I fixed a few more bugs last
> night), and interface-based access control works correctly.  Right now,
Cool. Today i cvsuped the rest of your commit and will try to compile
kernel.

> I'm focussing a bit of time on getting a basic TE implementation working,
> and then will move back to the network stack to integrate your CIPSO code,
> and broaden support for access control on interfaces (support label ranges
> not just equality tests for outgoing packets).
So i have to read TE docs, that Tim sent me a year ago, to fresh my memory
about that policy.

Happy New year to everybody!


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message