[redhat-lspp] Labeled networking MLS constraints?

[Klaus Weidner]

On Tue, Oct 17, 2006 at 08:36:07AM -0400, Paul Moore wrote:
> On Monday 16 October 2006 9:49 pm, Klaus Weidner wrote:
> > So for the calls that use unconnected sockets, for example recvfrom() and
> > recvmsg() for UDP communication, the socket's label should always be the
> > same as the process label, right?
> 
> By default yes, but don't forget about setsockcreatecon() and sockets create 
> by accept() when labeled networking is active on that connection.

Yes - at least setsockcreatecon() won't be available to unprivileged
processes (or rather, the context can be assigned successfully but won't
work...). I guess "unconnected" isn't a very helpful distinction here, in
the case of accept() you need a bound socket, but it isn't connected yet.

> > For recvmsg/recvfrom with unconnected sockets (for example UDP), that
> > should mean that incoming packets get dropped in the packet/socket check,
> > and that the read call will never fail due to missing MLS rights - it
> > just won't get any data.
> 
> I'm only going to speak about the recvfrom permission as that is what 
> NetLabel/CIPSO uses, if I remember correctly recvmsg is only used by the 
> compat_net method of determining local packet labels.

I had meant the recvfrom() system call/library function, not the name
used in the constraints. Are the access check locations the same with and
without compat_net?

> There are basically two checks a packet with CIPSO tagging must face before it 
> can be "read" by a process.  The first check is a check between the generated 
> (explained above) NetLabel packet context and the receiving socket's context; 
> this uses the "recvfrom" permission.  The second check is between the 
> processes' domain and the socket's context; this uses the normal socket read 
> permissions.

If I understand things right, the first check would generally succeed for
packets within open TCP sessions (assuming no packet tampering) since the
socket MLS label was set based on the handshake packets, and the second
check is the security enforcing one that ensures the process can't
read/write at the wrong level?

> > For sendto/sendmsg, the MLS check would happen at 
> > the receiving machine, does this mean that there is no MLS enforcement
> > for sending packets out at this level? Will they get dropped if there is
> > no valid CIPSO DOI mapping or SELinux SA?
> 
> NetLabel does not impose any additional restrictions on sending data (other 
> then denying the send if it can not label the data as intended by the 
> configuration).  This is largely due to the fact that CIPSO does not do any 
> sort of negotiation between hosts; it simply attaches the security attributes 
> to a packet and dumps the packet on the wire.

So if you configure a DOI that only defines certain levels and categories
(say, up to s1:c0.c7), does that ensure that packets won't be sent out at
higher levels?

> I believe labeled IPsec does add an additional restriction on sending data as 
> it can use the outbound SA; perhaps Joy or Venkat can explain this in further 
> detail.

/me hopes for more detail...

-Klaus