selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Impact of IPSEC integration on policy
@ 2005-12-05 14:17 Stephen Smalley
  2005-12-05 20:41 ` James Morris
  0 siblings, 1 reply; 2+ messages in thread
From: Stephen Smalley @ 2005-12-05 14:17 UTC (permalink / raw)
  To: selinux
  Cc: Trent Jaeger, James Morris, Russell Coker,
	Christopher J. PeBenito, Daniel J Walsh

Hi,

As a heads-up, the LSM-IPSEC network hooks patches by Trent that are
queued up for 2.6.16 (and already in -mm) have an impact on policy
(assuming people enable CONFIG_SECURITY_NETWORK_XFRM) even if not using
IPSEC.  We need to add rules to policy on the 'association' class to
allow sending and receiving of non-IPSEC protected packets (aka
unlabeled packets); otherwise, network traffic is going to be dropped.
The checks are between the socket SID and the unlabeled SID when no
association is used.  So I think it would look like:

allow $1 unlabeled_t:association { sendto recvfrom };

in the networking macros and in the unconfined macro.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Impact of IPSEC integration on policy
  2005-12-05 14:17 Impact of IPSEC integration on policy Stephen Smalley
@ 2005-12-05 20:41 ` James Morris
  0 siblings, 0 replies; 2+ messages in thread
From: James Morris @ 2005-12-05 20:41 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: selinux, Trent Jaeger, Russell Coker, Christopher J. PeBenito,
	Daniel J Walsh

On Mon, 5 Dec 2005, Stephen Smalley wrote:

> Hi,
> 
> As a heads-up, the LSM-IPSEC network hooks patches by Trent that are
> queued up for 2.6.16 (and already in -mm) have an impact on policy
> (assuming people enable CONFIG_SECURITY_NETWORK_XFRM) even if not using
> IPSEC.  We need to add rules to policy on the 'association' class to
> allow sending and receiving of non-IPSEC protected packets (aka
> unlabeled packets); otherwise, network traffic is going to be dropped.
> The checks are between the socket SID and the unlabeled SID when no
> association is used.  So I think it would look like:
> 
> allow $1 unlabeled_t:association { sendto recvfrom };
> 
> in the networking macros and in the unconfined macro.

Agreed.



-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-12-05 20:47 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-12-05 14:17 Impact of IPSEC integration on policy Stephen Smalley
2005-12-05 20:41 ` James Morris

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).