From sacadmin Fri Jun 16 11:59:07 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5GIx6AW000658 for ; Fri, 16 Jun 2006 11:59:07 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5GIxuDm022403; Fri, 16 Jun 2006 14:59:56 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5GIxuqn022400; Fri, 16 Jun 2006 14:59:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17554.65452.923095.420394@gargle.gargle.HOWL> Date: Fri, 16 Jun 2006 14:59:56 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: will.young@sun.com Subject: 2006/397 Route Get Security Attributes X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 5047 I'm sponsoring this fast-track request for Will Young. The timer is set to 06/23/2006. Change Summary: Add "sl=" keyword for route(1M) Stable Change RTM_GET to accept label Stable route(1M) output for "get" Unstable netstat(1m) output for "-rR" Unstable Binding: These changes are intended for the "Micro/Patch" binding. The affected operations require Trusted Extensions as described in "Layered Trusted Solaris" (PSARC 2002/762), which has not officially released so incompatibility is not a concern. Background: route(1m) is extended for systems running Solaris Trusted Extensions(TX) to accept and apply security attributes when adding or modifying a route. The format of these security attributes includes a lower and upper TX/CIPSO sensitivity label to represent the range of labels the route is relevant for. TX also has a mechanism for determining if a route that lacks explicit security attributes applies to a given label. The route command also has a 'get' subcommand which is intended to display the route the system would use to reach a destination for debugging purposes. Since TX filters routes based on the requester's label it is necessary for this command to apply the same rules based on the caller's sensitivity label to provide a route to the destination that is valid for the caller. Proposal: This case proposes accepting security attributes when getting a route to allow a caller to debug routing for other labels and add a new 'sl=' token to the route -secattr flag to simplify usage and display of single label ranges. The security attributes will be used in place of the caller's label to search for an applicable route if the caller's sensitivity label dominates them or the caller is in the global zone. This will allow an administrator to debug routing on a TX gateway which is routing for labels that have no local zone. It will also allow a user or administrator to debug routing for all of their sensitivity label range from a terminal at their highest sensitivity label. Since one gets a route based on a single label but sets security attributes with a range, the existence of both a min_sl and max_sl is redundant in route get usage. A sl= token will be added which is equivalent to using the existing min_sl= and max_sl= with the same label. The sl= token may be used in replacement for specifying both min_sl= and max_sl= whenever for any usage of route security attributes, currently route get, change and add. When displaying a range where min_sl equals max_sl, the output will also be compacted from "min_sl=LABEL,max_sl=LABEL" to a single display of sl=LABEL. Related work: "TSNET: Trusted Networking with Security" (PSARC 2005/060) has added an optional sl_set property for hosts and gateways to simplify administration for sites that represent labels as discrete rather than as a range. In contrast, this proposal does not add additional capabilities for handling multiple discrete labels in routes, but does simplify syntax those using routing security attributes for one discrete label. Man page level diffs follow: zhadum% diff -c route.1m.orig route.1m *** route.1m.orig Fri Jun 16 12:29:50 2006 --- route.1m Fri Jun 16 12:32:45 2006 *************** *** 493,511 **** The -secattr modifier has the following format: ! min_sl=val,max_sl=val,doi=val,cipso ! ! The val for min_sl and max_sl is a sensitivity label in ! either hex or string form. The val for doi is a non- negative integer. The route will apply only for packets with the same domain of interpretation as defined by the ! doi value and within the accredation range defined by the min_sl and max_sl values. The cipso keyword is optional and set by default. Valid min_sl, max_sl and ! doi keyword/value pairs are mandatory. Note that if val contains a space, it must be protected by double quotes. --- 493,517 ---- The -secattr modifier has the following format: + min_sl=VAL,max_sl=VAL,doi=VAL,cipso + or: + sl=VAL,doi=VAL,cipso ! In the first form the VAL for min_sl and max_sl is a ! sensitivity label in ! either hex or string form. The VAL for doi is a non- negative integer. The route will apply only for packets with the same domain of interpretation as defined by the ! doi value and within the accreditation range defined by the min_sl and max_sl values. The cipso keyword is optional and set by default. Valid min_sl, max_sl and ! doi keyword/value pairs are mandatory. Note that if VAL contains a space, it must be protected by double quotes. + The second form is equivalent to specifying the first form + with the same VAL for min_sl and max_sl. The second form + should be used for the get command since get uses only + a single sensitivity label. From sacadmin Mon Jun 19 21:26:40 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5K4Qeda014242 for ; Mon, 19 Jun 2006 21:26:40 -0700 (PDT) Received: from [129.146.11.202] (sr1-umpk-18.SFBay.Sun.COM [129.146.11.202]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5K4QcXe110763; Mon, 19 Jun 2006 21:26:38 -0700 (PDT) Message-ID: <449778FE.1030003@Sun.COM> Date: Mon, 19 Jun 2006 21:26:38 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: James Carlson CC: psarc@sac.sfbay.sun.com, will.young@Sun.COM Subject: Re: 2006/397 Route Get Security Attributes References: <17554.65452.923095.420394@gargle.gargle.HOWL> In-Reply-To: <17554.65452.923095.420394@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 463 James Carlson wrote On 06/16/06 11:59,: >I'm sponsoring this fast-track request for Will Young. The timer is >set to 06/23/2006. > > >Change Summary: > > Add "sl=" keyword for route(1M) Stable > Change RTM_GET to accept label Stable > route(1M) output for "get" Unstable > > does it make sense to do the same for the route "monitor" ? monitiring the changes for a label range for example? Kais > netstat(1m) output for "-rR" Unstable > > > > From sacadmin Tue Jun 20 07:30:34 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5KEUX0t026811 for ; Tue, 20 Jun 2006 07:30:33 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5KEUXUQ002319 for ; Tue, 20 Jun 2006 07:30:33 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5KEUXr3007338 for ; Tue, 20 Jun 2006 08:30:33 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1500201X5JHD00@mail-amer.sun.com> (original mail from will.young@sun.com) for psarc@sac.sfbay.sun.com; Tue, 20 Jun 2006 08:30:33 -0600 (MDT) Received: from [129.148.176.182] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1500AKNXM5VT22@mail-amer.sun.com>; Tue, 20 Jun 2006 08:30:32 -0600 (MDT) Date: Tue, 20 Jun 2006 10:27:20 -0400 From: Will Young Subject: Re: 2006/397 Route Get Security Attributes In-reply-to: <449778FE.1030003@Sun.COM> Sender: William.Young@sun.com To: Kais Belgaied Cc: James Carlson , psarc@sac.sfbay.sun.com Message-id: <449805C8.1060804@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <17554.65452.923095.420394@gargle.gargle.HOWL> <449778FE.1030003@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060405 Status: RO Content-Length: 1568 Kais Belgaied wrote: > > > James Carlson wrote On 06/16/06 11:59,: > >> I'm sponsoring this fast-track request for Will Young. The timer is >> set to 06/23/2006. >> >> >> Change Summary: >> >> Add "sl=" keyword for route(1M) Stable >> Change RTM_GET to accept label Stable >> route(1M) output for "get" Unstable >> >> > > does it make sense to do the same for the route "monitor" ? monitiring > the changes for a label > range for example? The requirement proposed for the requester's label to dominate any label they provide via security attributes are to limit the changes needed to `route get` if we later implement "route privacy". (Route privacy would restrict the routes that are visible to a process based on its sensitivity label.) To implement "route privacy" we would have to implement similar changes to `route monitor` as you suggest, but there are a number of other areas that would need to change as well (i.e. the netsat/mib interface.) I don't think it is appropriate to make similar changes to `route monitor` unless it were part of a full "route privacy" project since in solaris `route monitor` is not inherently filtering like `route get`. If for example it were possible to restrict `route monitor` to print only changes associated with a specific gateway in solaris then I think this type of filtering on security attributes would be directly applicable to `route monitor` as well. -Will > > Kais > > >> netstat(1m) output for "-rR" Unstable >> >> >> >> From sacadmin Tue Jun 20 07:36:25 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5KEaOkZ026852 for ; Tue, 20 Jun 2006 07:36:24 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5KEbGI1001113; Tue, 20 Jun 2006 10:37:17 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5KEbGZn001110; Tue, 20 Jun 2006 10:37:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17560.2074.747500.995106@gargle.gargle.HOWL> Date: Tue, 20 Jun 2006 10:37:14 -0400 From: James Carlson To: Will Young Cc: Kais Belgaied , psarc@sac.sfbay.sun.com Subject: Re: 2006/397 Route Get Security Attributes In-Reply-To: Will Young's message of 20 June 2006 10:27:20 References: <17554.65452.923095.420394@gargle.gargle.HOWL> <449778FE.1030003@Sun.COM> <449805C8.1060804@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1181 Will Young writes: > I don't think it is appropriate to make similar changes to > `route monitor` unless it were part of a full "route privacy" project > since in solaris `route monitor` is not inherently filtering like `route > get`. If for example it were possible to restrict `route monitor` to > print only changes associated with a specific gateway in solaris then I > think this type of filtering on security attributes would be directly > applicable to `route monitor` as well. I think the underlying question here might be simpler than that: given that you're putting the route attribute (label) on the RTM_GET command, will users doing "route monitor" see this? The answer (I think) should be "yes:" the intentional design model for BSD routing sockets is that all listeners see all commands and responses sent by others. Given that, the question is whether "route monitor" formats that for text output. I'd expect that it does. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Jun 20 09:12:47 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5KGCllx001186 for ; Tue, 20 Jun 2006 09:12:47 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5KGCk0x013869; Tue, 20 Jun 2006 09:12:46 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k5KGDnTo000417; Tue, 20 Jun 2006 09:13:49 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k5KGDn6t000416; Tue, 20 Jun 2006 09:13:49 -0700 (PDT) Date: Tue, 20 Jun 2006 09:13:49 -0700 (PDT) From: Gary Winiger Message-Id: <200606201613.k5KGDn6t000416@marduk.eng.sun.com> To: james.d.carlson@sun.com, will.young@sun.com Cc: Kais.Belgaied@sun.com, psarc@sac.sfbay.sun.com Subject: Re: 2006/397 Route Get Security Attributes Status: RO Content-Length: 523 > that you're putting the route attribute (label) on the RTM_GET > command, will users doing "route monitor" see this? The answer (I > think) should be "yes:" the intentional design model for BSD routing > sockets is that all listeners see all commands and responses sent by > others. > > Given that, the question is whether "route monitor" formats that for > text output. I'd expect that it does. I presumed that get and monitor would have the same security policy. Read down. If that's not the case, why? Gary.. From sacadmin Wed Jun 21 11:37:07 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5LIb7Xs015288 for ; Wed, 21 Jun 2006 11:37:07 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k5LIb6VY020205 for ; Wed, 21 Jun 2006 11:37:07 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5LIb5QN002869 for ; Wed, 21 Jun 2006 12:37:06 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J180020139DPO00@mail-amer.sun.com> (original mail from will.young@sun.com) for psarc@sac.sfbay.sun.com; Wed, 21 Jun 2006 12:37:04 -0600 (MDT) Received: from [129.150.66.146] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1800D1H3PPEEA5@mail-amer.sun.com>; Wed, 21 Jun 2006 12:37:03 -0600 (MDT) Date: Wed, 21 Jun 2006 14:38:16 -0400 From: will young Subject: Re: 2006/397 Route Get Security Attributes In-reply-to: <200606201613.k5KGDn6t000416@marduk.eng.sun.com> Sender: William.Young@sun.com To: Gary Winiger Cc: James.D.Carlson@sun.com, Kais.Belgaied@sun.com, psarc@sac.sfbay.sun.com Message-id: <44999218.70301@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200606201613.k5KGDn6t000416@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.2 (X11/20060515) Status: RO Content-Length: 1865 Gary Winiger wrote: >> that you're putting the route attribute (label) on the RTM_GET >> command, will users doing "route monitor" see this? The answer (I >> think) should be "yes:" the intentional design model for BSD routing >> sockets is that all listeners see all commands and responses sent by >> others. >> >> Given that, the question is whether "route monitor" formats that for >> text output. I'd expect that it does. > > I presumed that get and monitor would have the same security > policy. Read down. If that's not the case, why? There are two distinct issues being raised. Covert channels between processes in different zones/labels and access to information pertaining to the routes for different zones/labels (lack of "routing privacy".) The covert channel issues for sockets is addressed by "TSNET: Trusted Networking with Security" (PSARC 2005/060), if the code for routing sockets does not conform I will file CRs. There is an inherent covert channel between processes capable of adding/modifying/deleting routes and those capable of using or displaying any route. This issue is partly handled by privilege and this proposal(PSARC 2006/397) is neutral to that issue. The access to information on routes for other zones/labels is not addressed by PSARC 2005/060 nor will it be addressed by this proposal. This proposal changes the behavior of RTM_GET in TX primarily for usability. I don't believe any other interfaces would benefit from similar changes from the standpoint of usability. This proposal also improves RTM_GET with regards to "routing privacy" beyond the standards for other interfaces. I do not believe other interfaces can be equally improved without a larger project introducing considerably more TX specific logic. Current requirements do not make the larger project a priority. Thanks, -Will > > Gary.. From sacadmin Wed Jun 21 12:35:11 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5LJZB4n017382 for ; Wed, 21 Jun 2006 12:35:11 -0700 (PDT) Received: from [129.146.11.202] (sr1-umpk-18.SFBay.Sun.COM [129.146.11.202]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5LJZBxd288091; Wed, 21 Jun 2006 12:35:11 -0700 (PDT) Message-ID: <44999F6E.8010106@Sun.COM> Date: Wed, 21 Jun 2006 12:35:10 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: will young CC: Gary Winiger , James.D.Carlson@Sun.COM, psarc@sac.sfbay.sun.com Subject: Re: 2006/397 Route Get Security Attributes References: <200606201613.k5KGDn6t000416@marduk.eng.sun.com> <44999218.70301@sun.com> In-Reply-To: <44999218.70301@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1094 will young wrote On 06/21/06 11:38,: > > This proposal changes the behavior of RTM_GET in TX primarily for >usability. I don't believe any other interfaces would benefit from > > the choice of implementing the label filtering for usability convenience in kernel (rts' processing of RTM_GET) as opposed to userland route get code is what triggered my original question (and possibly Gary's). It led to believe that there is some finer MAC policy enforcement being added. So, what is the motivation for that choice? >similar changes from the standpoint of usability. This proposal also >improves RTM_GET with regards to "routing privacy" beyond the standards > > that can't be sufficient if route monitor isn't equally enhenced. It's like barricading the windows while leaving the door open. Kais. >for other interfaces. I do not believe other interfaces can be equally >improved without a larger project introducing considerably more TX >specific logic. Current requirements do not make the larger project a >priority. > > Thanks, > -Will > > >>Gary.. >> >> > > > From sacadmin Wed Jun 21 13:40:44 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5LKei7e020782 for ; Wed, 21 Jun 2006 13:40:44 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k5LKehAo012525 for ; Wed, 21 Jun 2006 13:40:43 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5LKefBG014118 for ; Wed, 21 Jun 2006 14:40:43 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J180070198TWX00@mail-amer.sun.com> (original mail from will.young@sun.com) for psarc@sac.sfbay.sun.com; Wed, 21 Jun 2006 14:40:41 -0600 (MDT) Received: from [129.150.66.146] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J18008W29FRPV20@mail-amer.sun.com>; Wed, 21 Jun 2006 14:40:41 -0600 (MDT) Date: Wed, 21 Jun 2006 16:41:55 -0400 From: will young Subject: Re: 2006/397 Route Get Security Attributes In-reply-to: <44999F6E.8010106@Sun.COM> Sender: William.Young@sun.com To: Kais Belgaied Cc: Gary Winiger , James.D.Carlson@sun.com, psarc@sac.sfbay.sun.com Message-id: <4499AF13.6070206@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200606201613.k5KGDn6t000416@marduk.eng.sun.com> <44999218.70301@sun.com> <44999F6E.8010106@Sun.COM> User-Agent: Thunderbird 1.5.0.2 (X11/20060515) Status: RO Content-Length: 1778 Kais Belgaied wrote: > > > will young wrote On 06/21/06 11:38,: > >> >> This proposal changes the behavior of RTM_GET in TX primarily for >> usability. I don't believe any other interfaces would benefit from >> >> > the choice of implementing the label filtering for usability convenience > in kernel > (rts' processing of RTM_GET) as opposed to userland route get code is what > triggered my original question (and possibly Gary's). It led to believe > that there is some > finer MAC policy enforcement being added. The change for existing usage is making `route get` without -secattr use the current processes sensitivity label since this is what a user is really asking. ("If I issued a request to host X what would be done?") This really just fixes route get for TX users. The -secattr change adds functionality. "Hypothetically if I were instead at label X what would be done?" We limit label X to be dominated by the current label for those not in the g-z. > > So, what is the motivation for that choice? We limit the bounds of the new functionality to those that would be imposed if there were "routing privacy" so that we do not introduce new functionality only to take it away if a routing privacy project is done. > > >> similar changes from the standpoint of usability. This proposal also >> improves RTM_GET with regards to "routing privacy" beyond the standards >> >> > that can't be sufficient if route monitor isn't equally enhenced. It's > like barricading > the windows while leaving the door open. The door is missing, but we would like to add one later. I am introducing a window and suggesting that it have glass. Demonstrating that glass would fit should technically be sufficient, but adding it now is easier. -Will > > Kais. > From sacadmin Sat Jun 24 20:05:46 2006 Received: from phys-gadget-1 (phys-gadget-1.UK.Sun.COM [129.156.85.171]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5P35jfT018099 for ; Sat, 24 Jun 2006 20:05:45 -0700 (PDT) Received: from conversion-daemon.gadget-mail1.uk.sun.com by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0J1E00501AUPF0@gadget-mail1.uk.sun.com> (original mail from paul.jakma@sun.com) for psarc@sac.sfbay.sun.com; Sun, 25 Jun 2006 04:05:45 +0100 (BST) Received: from vpn-129-150-120-54.UK.Sun.COM (vpn-129-150-120-54.UK.Sun.COM [129.150.120.54]) by gadget-mail1.uk.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0J1E00EOJB9JJ5@gadget-mail1.uk.sun.com>; Sun, 25 Jun 2006 04:05:45 +0100 (BST) Date: Sun, 25 Jun 2006 04:03:59 +0100 (IST) From: Paul Jakma Subject: Re: 2006/397 Route Get Security Attributes In-reply-to: <17554.65452.923095.420394@gargle.gargle.HOWL> Sender: pj149606@gadget-mail1.uk.sun.com To: James Carlson Cc: psarc@sac.sfbay.sun.com, William.Young@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed References: <17554.65452.923095.420394@gargle.gargle.HOWL> Status: RO Content-Length: 1934 Hi, NB: I'm not a member of PSARC in any way - if it's bad form for me to send mail to this list, apply LART.. On Fri, 16 Jun 2006, James Carlson wrote: > route(1m) is extended for systems running Solaris Trusted > Extensions(TX) to accept and apply security attributes when adding or > modifying a route. The format of these security attributes includes a > lower and upper TX/CIPSO sensitivity label to represent the range of > labels the route is relevant for. TX also has a mechanism for > determining if a route that lacks explicit security attributes applies > to a given label. Couple of questions: 1. Does this affect the PF_ROUTE socket? If so: 2. What are the intended applications of this per-route labeling exactly? Squashing covert channels I gather from another email. That leads to me to ask: Is this intended to prevent visibility of a route to applications without the required sensitivity generally, or simply solely via PF_ROUTE? 2a. If generally, will there also be per-label routing tables and/or IP stack? If not, isn't PF_ROUTE labeling premature - for the covert channel would remain (just slightly less direct)? If there is future work to close that further covert channel off, should the dependency perhaps be noted? 2b. I presume ultimately its meant to be general, but just in case it isn't: If solely PF_ROUTE, what's the point exactly? (covert channel remains - see previous) > The route command also has a 'get' subcommand which is intended to > display the route the system would use to reach a destination for > debugging purposes. For the record (if this case affects PF_ROUTE, not just 'route'): GET can have uses besides debug (error recovery in stateful routing-socket applications). regards, -- Paul Jakma, Network Approachability, KISS. Sun Microsystems, Dublin, Ireland. http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 819 9190 From sacadmin Sun Jun 25 08:40:18 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5PFeH9b029674 for ; Sun, 25 Jun 2006 08:40:18 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5PFfFt2018058; Sun, 25 Jun 2006 11:41:15 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5PFfF1n018055; Sun, 25 Jun 2006 11:41:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17566.44699.190134.30869@gargle.gargle.HOWL> Date: Sun, 25 Jun 2006 11:41:15 -0400 From: James Carlson To: Paul Jakma Cc: psarc@sac.sfbay.sun.com, William.Young@sun.com Subject: Re: 2006/397 Route Get Security Attributes In-Reply-To: Paul Jakma's message of 25 June 2006 04:03:59 References: <17554.65452.923095.420394@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 3824 Paul Jakma writes: > > route(1m) is extended for systems running Solaris Trusted > > Extensions(TX) to accept and apply security attributes when adding or > > modifying a route. The format of these security attributes includes a > > lower and upper TX/CIPSO sensitivity label to represent the range of > > labels the route is relevant for. TX also has a mechanism for > > determining if a route that lacks explicit security attributes applies > > to a given label. > > Couple of questions: > > 1. Does this affect the PF_ROUTE socket? Yes. But then so does the original TX project. With Trusted Extensions, you will see labels on routes. It's a fairly restricted environment, though, as "normal" systems are not labeled. > 2. What are the intended applications of this per-route labeling > exactly? Squashing covert channels I gather from another email. Not exactly. You need to read through PSARC 2002/762, 2005/060, and 2005/259 to get the background information on Trusted Extensions. The short answer is that with a "trusted" system, everything is labeled, and there are rules that govern how information may flow between processes and users with different labels. In many ways, it has nothing to do with "security" as we generally know it. For one thing, the labels on the wire are in the clear. "Trust" means essentially that the system is assumed to be operating correctly, not that it actually is safe. > That > leads to me to ask: > > Is this intended to prevent visibility of a route to applications > without the required sensitivity generally, or simply solely via > PF_ROUTE? Neither. > 2a. If generally, will there also be per-label routing tables and/or IP > stack? If not, isn't PF_ROUTE labeling premature - for the covert > channel would remain (just slightly less direct)? If there is future > work to close that further covert channel off, should the dependency > perhaps be noted? No, none of that applies. There aren't per-label routing tables, and this case really has nothing to do with how labeling works in Trusted Extensions. Instead, this case is _just_ about an extension to RTM_GET that goes along with the _existing_ labeled RTM_ADD and other routing socket changes already present in Trusted Extensions. You need to look at 2005/060 "TSNET: Trusted Networking with Security Labels." > 2b. I presume ultimately its meant to be general, but just in case it > isn't: If solely PF_ROUTE, what's the point exactly? (covert channel > remains - see previous) Yes the channel does remain. That's what the "privacy" issue that the original submitter was disclaiming was about. This case doesn't improve on that situation. > > The route command also has a 'get' subcommand which is intended to > > display the route the system would use to reach a destination for > > debugging purposes. > > For the record (if this case affects PF_ROUTE, not just 'route'): GET > can have uses besides debug (error recovery in stateful routing-socket > applications). Yes. But Trusted Extensions does not yet have label-enhanced routing protocols. That part was explicitly excluded from the original project for schedule and resource reasons. Label-enhanced routing protocols are something that may be done in the future. For now, it supports static routing _only_. The Trusted Solaris 8 product that's being replaced here does have label-enhanced RIP. I would assume that an extension like TS8's in.routed would be the first thing to appear when resources are available to design and implement it. This project isn't about that, though. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Jun 28 10:20:15 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5SHKEdx001892 for ; Wed, 28 Jun 2006 10:20:14 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5SHLFVR028767; Wed, 28 Jun 2006 13:21:15 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5SHLFQ6028764; Wed, 28 Jun 2006 13:21:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17570.47753.38641.370176@gargle.gargle.HOWL> Date: Wed, 28 Jun 2006 13:21:13 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: will.young@sun.com Subject: Re: 2006/397 Route Get Security Attributes In-Reply-To: James Carlson's message of 16 June 2006 14:59:56 References: <17554.65452.923095.420394@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 388 This fast-track request was approved at today's PSARC meeting. I've placed a final specification (with an added note about "route privacy") in the case directory. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677