[redhat-lspp] [PATCH] lsm-secpeer for IPSec labels

[Roe, William H.]

Paul,

It is very likely that the current IPSEC networking scheme may NOT be
accreditable above DCID 6/3 PL3.  The issue is confirmation of the
origin of the system connecting.  It has to be differentiated at the
packet level othewise you limit the extensibility of the network to only
those known to be at the same classification level, though you may allow
different compartments via encryption segregation.  

DCID 6/3 Label1 and Label2 REQUIRE the explicit electronic labeling of
media.  Label1 and Label2 are required for deployment of PL4 systems.
Implict or inference labeling are only allowed at PL3 and below.  That
bascially means that everyone on the network HAS to have the SAME
security clearance, but do not have to have the same need to know which
is a PL3 not PL4 network.

Check it out.

DCID 6/3 Table D.1 PL4 Column
D-15 [Label1] and [Label2] define the electronic label requirement.

The real interpretation of this requirement should be done by the NSA
certifiers/accreditors.  It is their interpretation that matters.

William Roe, CISSP, M.S. IA
General Dynamics AIS
Intelligence Mission Solutions
Technical Engineering Matrix Manager
Sr. Lead Software Engineer
410/859-2076 office
443/220-8910 blackberry
william.roe at gd-ais.com
 
Confidentiality Note:  This e-mail is intended only for the person or
entity to which it is addressed, and may contain information that is
privileged, confidential, or otherwise protected from disclosure.
Dissemination, distribution, or copying of this e-mail or the
information herein by anyone other than the intended recipient is
prohibited.  If you have received this e-mail in error, please notify
the sender by reply e-mail, phone, or fax, and destroy the original
message and all copies.  Thank you.


-----Original Message-----
From: Paul Moore [mailto:paul.moore at hp.com] 
Sent: Wednesday, September 14, 2005 5:31 PM
To: Roe, William H.
Subject: Re: [redhat-lspp] [PATCH] lsm-secpeer for IPSec labels

Roe, William H. wrote:
> Paul it sounds like it would be easier to label at the ip layer, since

> both udp and tcp ride ip.  UDP support would enable you to provide 
> label compatibility with legacy NFS... Version 2 and prior.
> 
> Bill

Hi Bill,

The current IPsec based approach does in fact label at the IP layer. 
While IPsec/IKE can use higher level protocols such as TCP and UDP as
selectors the transforms happen at the IP level.  The problem I was
referring to was that the patch only allows applications to get the
SELinux context for a connected TCP socket, not a UDP socket.  Granted
the TCP case is probably far more useful but I think there should be a
solution to handle more than just TCP.

Also, for what it is worth I was happy to hear on the call earlier today
that explicit packet labeling is very important to you guys.  I
personally have some pretty strong reservations about the current
IPsec/implicit-labeling approach but I seem to be the only one.

> William Roe, CISSP, M.S. IA
> General Dynamics AIS
> Intelligence Mission Solutions
> Technical Engineering Matrix Manager
> Sr. Lead Software Engineer
> 410/859-2076 office
> 443/220-8910 blackberry
> william.roe at gd-ais.com
>  
>  
> 
> Confidentiality Note:  This e-mail is intended only for the person or 
> entity to which it is addressed, and may contain information that is 
> privileged, confidential, or otherwise protected from disclosure.
> Dissemination, distribution, or copying of this e-mail or the 
> information herein by anyone other than the intended recipient is 
> prohibited.  If you have received this e-mail in error, please notify 
> the sender by reply e-mail, phone, or fax, and destroy the original 
> message and all copies.  Thank you.
> 
> 
> -----Original Message-----
> From: redhat-lspp-bounces at redhat.com
> [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of Paul Moore
> Sent: Wednesday, September 14, 2005 11:26 AM
> To: redhat-lspp at redhat.com
> Subject: Re: [redhat-lspp] [PATCH] lsm-secpeer for IPSec labels
> 
> George Wilson wrote:
> 
>>The patch enables the SELinux LSM to set the peer security context for
> 
> 
>>a socket based on the security context of the IPSec security 
>>association.  The application may retrieve this context using 
>>getsockopt.  When called, the kernel determines if the socket is a 
>>connected (TCP_ESTABLISHED) TCP socket and, if so, uses the dst_entry 
>>cache on the socket to retrieve the security associations.  If a 
>>security association has a security context, the context string is 
>>returned, as for UNIX domain sockets.
>>
> 
> 
> Is there any reason why we are limiting ourselves to connected TCP 
> sockets?  I understand that due to the nature of the sockets and the 
> fact that we are only implicitly labeling them via the SA it would be 
> much more difficult, but what about UDP based applications?
> 
> --
> . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
> . paul.moore at hp.com                                      hewlett
packard
> . (603) 884-5056                                          linux
security
> 
> --
> redhat-lspp mailing list
> redhat-lspp at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-lspp


--
. paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. paul.moore at hp.com                                      hewlett packard
. (603) 884-5056                                          linux security