Re: Secdir Review of draft-stjohns-sipso-05

[Michael StJohns <mstjohns at comcast.net>]

At 07:01 PM 10/2/2008, Joe Touch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>> A second single level process at SECRET also attempts to do a passive
>> open to the same port - but gets blocked because the port resource is
>> being held by the TOP SECRET process. The SECRET process now has one bit
>> of information about the TOP SECRET part of the host. By grabbing and
>> releasing port resources, the TS process can signal data to processes at
>> lower security levels.
>
>Understood. However, the lower security process can't know whether it's
>the TS process doing this or some other reason (port blocked, e.g.); all
>it knows is that it can't connect at the level it wants on
>the port it wants.

MLS systems have a couple of mandatory access rules - one of them is that processes at higher levels can read things at lower levels (assuming the discretionary access controls permit it).  This includes specifically, programs.

Say you have an attacker - a contract programmer hired by Coke to write a couple of utility programs.  He writes two - one programFrom ietf-bounces at ietf.org  Thu Oct  2 17:16:21 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 884C93A6AC9;
	Thu,  2 Oct 2008 17:16:21 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 519F13A6AC9
	for <ietf at core3.amsl.com>; Thu,  2 Oct 2008 17:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.665
X-Spam-Level: 
X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.934, 
	BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 0M7VT3SI3Li1 for <ietf at core3.amsl.com>;
	Thu,  2 Oct 2008 17:16:19 -0700 (PDT)
Received: from QMTA03.emeryville.ca.mail.comcast.net
	(qmta03.emeryville.ca.mail.comcast.net [76.96.30.32])
	by core3.amsl.com (Postfix) with ESMTP id 81D3E3A68BB
	for <ietf at ietf.org>; Thu,  2 Oct 2008 17:16:19 -0700 (PDT)
Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52])
	by QMTA03.emeryville.ca.mail.comcast.net with comcast
	id N0Co1a00417UAYkA30GivB; Fri, 03 Oct 2008 00:16:42 +0000
Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110])
	by OMTA13.emeryville.ca.mail.comcast.net with comcast
	id N0Ge1a00F2P9w058Z0GemQ; Fri, 03 Oct 2008 00:16:40 +0000
X-Authority-Analysis: v=1.0 c=1 a=eBNOf6ryCRIA:10 a=fKVHrc5Tc7QA:10
	a=Owv6ZZ2Rw8-U34hl7I4A:9 a=6rTn9vM3xUDX0qquihgA:7
	a=mnEL5EjJvzZSc67VlQQppDObL2oA:4 a=h9s5Ru71U4oA:10
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 02 Oct 2008 20:16:39 -0400
To: Joe Touch <touch at ISI.EDU>
From: Michael StJohns <mstjohns at comcast.net>
Subject: Re: Secdir Review of draft-stjohns-sipso-05
In-Reply-To: <48E552AD.2080209 at isi.edu>
References: <tslprmm3gjs.fsf at mit.edu> <20080929170305.4740f779 at cs.columbia.edu>
	<tslljx9zzdu.fsf at mit.edu> <20081001221217.3921b69e at cs.columbia.edu>
	<20081002093129.5bb80658 at cs.columbia.edu>
	<48E51069.1040403 at isi.edu>
	<200810021857.m92IvIYY027621 at vapor.isi.edu>
	<48E552AD.2080209 at isi.edu>
Mime-Version: 1.0
Message-Id: <20081003001619.81D3E3A68BB at core3.amsl.com>
Cc: ietf at ietf.org, draft-stjohns-sipso-05 at tools.ietf.org,
	Sam Hartman <hartmans-ietf at mit.edu>, secdir at mit.edu
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

At 07:01 PM 10/2/2008, Joe Touch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>> A second single level process at SECRET also attempts to do a passive
>> open to the same port - but gets blocked because the port resource is
>> being held by the TOP SECRET process. The SECRET process now has one bit
>> of information about the TOP SECRET part of the host. By grabbing and
>> releasing port resources, the TS process can signal data to processes at
>> lower security levels.
>
>Understood. However, the lower security process can't know whether it's
>the TS process doing this or some other reason (port blocked, e.g.); all
>it knows is that it can't connect at the level it wants on
>the port it wants.

MLS systems have a couple of mandatory access rules - one of them is that processes at higher levels can read things at lower levels (assuming the discretionary access controls permit it).  This includes specifically, programs.

Say you have an attacker - a contract programmer hired by Coke to write a couple of utility programs.  He writes two - one program that al that almost everyone will use at some point, another for his own personal use.  The former includes the signaling code to twiddle TCP ports.  The latter contains the code to monitor that twiddling.  The attacker completes his program, checks it in for use.  Mr VP comes along, logs in at TOP SECRET and runs the utility program - maybe its a spell checker - and triggers the signaling process.  The utility program has access to everything Mr VP has at that level. One of the things the trojan horse finds is the formula for New Coke (tm).. :-)  The attacker (at the UNCLASSIFIED level) captures the signals and ultimately the formula and sells the formula to the highest bidder.


The signaling program uses 10 ports - two to signal the presences or absence of data - and  8 others to represent one byte of data.  (See the old 1822 protocol definitions).


>...
>> The fix was to virtualize TCP so that there was a complete set of TCP
>> ports per distinct security domain.
>
>I agree that this fixes your problem, but what it does is create a new
>naming dimension to the entire Internet, and I don't think that this is
>feasible.

Naming?  Not really.  Addressing maybe - but that's - as I said before - pretty local to only those hosts that implement MLS.


>Perhaps you'd prefer to black-hole the SYNs at the wrong security level,
>which would still modify 793, but would not create the naming dimension
>problem that concerns me...

Define "wrong security level" - both the attacker and victim are operating at their own security levels, its just the resource interactions that lead to the covert channel.

Which SYN's - (need an exact filter definition here please) would you black hole, and how would that solve anything?



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


most everyone will use at some point, another for his own personal use.  The former includes the signaling code to twiddle TCP ports.  The latter contains the code to monitor that twiddling.  The attacker completes his program, checks it in for use.  Mr VP comes along, logs in at TOP SECRET and runs the utility program - maybe its a spell checker - and triggers the signaling process.  The utility program has access to everything Mr VP has at that level. One of the things the trojan horse finds is the formula for New Coke (tm).. :-)  The attacker (at the UNCLASSIFIED level) captures the signals and ultimately the formula and sells the formula to the highest bidder.


The signaling program uses 10 ports - two to signal the presences or absence of data - and  8 others to represent one byte of data.  (See the old 1822 protocol definitions).


>...
>> The fix was to virtualize TCP so that there was a complete set of TCP
>> ports per distinct security domain.
>
>I agree that this fixes your problem, but what it does is create a new
>naming dimension to the entire Internet, and I don't think that this is
>feasible.

Naming?  Not really.  Addressing maybe - but that's - as I said before - pretty local to only those hosts that implement MLS.


>Perhaps you'd prefer to black-hole the SYNs at the wrong security level,
>which would still modify 793, but would not create the naming dimension
>problem that concerns me...

Define "wrong security level" - both the attacker and victim are operating at their own security levels, its just the resource interactions that lead to the covert channel.

Which SYN's - (need an exact filter definition here please) would you black hole, and how would that solve anything?



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf