[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-security-discuss
Subject:    Re: [security-discuss] what does all-zones applied to a physical
From:       Jarrett Lu <Jarrett.Lu () sun ! com>
Date:       2007-07-14 0:03:07
Message-ID: 469812BB.2090807 () sun ! com
[Download RAW message or body]

will young wrote:
> Elijah L. Reed wrote:
>  > Will,
>  >
>  > Thanks for the response. The original question was about a system with 2
>  > NICs but we have systems with various numbers of NICs. Still need a
>  > little clarification on the security of a system after applying
>  > all-zones to a physical interface. Currently we run TSOL 8 12/02 X86 and
>  > we use Interface Manager to set a range on an interface. We have systems
>  > with multiple NICs and one NIC may talk Unclassified, Confidential,
>  > Secret, and Top-Secret. Other NICs on the same system might only talk
>  > Unclassified.
>
>      We would like to support interface ranges (tnidb support) again, 
> but currently do not.  Currently you would really need to rely on 
> outside antispoofing (i.e. ipfilter) and accurate tnrhdb entries to get 
> most of the functionality.  There is not a lot that can be done for 
> verifying incoming traffic from a CIPSO host is on the correct interface 
> if the choice is purely label dependent. Per-zone interfaces help for 
> hosts in that they allow technologies that aren't label aware to filter 
> on ip instead, but the label/zone relationship is not completely direct.
>  >
>  > What I'm trying to understand in Solaris 10 TX is the following:
>  > If we configure interface iprb0 as all-zones with an IP address
>  > 192.168.3.100/24. Configure 4 labeled zones (Unclassified, Confidential,
>  > Secret, and Top-Secret) with only the all zones interface
>  > (192.168.3.100/24) for each labeled zone. Then configure another system
>  > identical. Will we be able to talk Confidential from one system to the
>  > other without breaking security of TX? We want to make sure if we are
>  > working in the Unclassified zone on one system we can not communicate
>  > with any zone on the remote system other than unclassified.
>
>      Yes, label enforcement, aka Mandatory Access Control (MAC), will 
> prevent communications between normal processes in zones with different 
> labels though technically this is by label not zone.  We have the 
> NET_MAC privileges(5) for situations where a service is trusted to 
> communicate outside its own label, i.e. a multilevel X server.
>
>  >
>  > We would like to be able to use one IP address per interface with
>  > multiple labeled zones using the interface. Currently from documentation
>  > I have seen we would need an IP address for global, one for VNI0, and
>  > one for each labeled zone. Following the documentation we would have
>  > around 21 IP address on a system with 4 NICs and 4 labeled zones. We
>  > want to make sure we do not break the security of Solaris TX. Again we
>  > would like to use only 4 IP addresses on a system with 4 NICs opposed to
>  > the 21 mentioned earlier.
>
>      Since a solaris system often contacts itself for services and some 
> of our services are multi-label from the administrative zone, it is 
> important to have an all-zones interface.  This hides the switch to 
> cross zone communication for trusted services from their clients.  There 
> are many possible network configurations and many don't have a real 
> interface that is suitable for all labels so the VNI all-zones interface 
> is the only safe recommendation without knowing all the details of the 
> particular network environment.
>
>      With the VNI all-zones there is still no reason physical networks 
> can't use all-zones as well.  From a security point of view the real 
> difference is that with all-zones you are not getting the affects of 
> Solaris' implementation for the network/zone relationship but still 
> getting TX's MAC enforcement.
>
>      TX's label enforcement alone should be complete and the all-zones 
> behavior better emulates a traditional trusted host able to receive 
> traffic at many labels on the same ip and deliver them appropriately to 
> the correctly labeled processes.
>
>      In your situation I think 5 ip addresses would be the 
> recommendation, you could cut it to 4 but you are then restricted on how 
> you can configure tnrhdb data for one of your real ips which may be 
> troublesome now or later.
>
>   

The VNI0 address is really for inter-zone communication on the local system,
mainly between global zone and labeled zones. This address should really be
a non-routable private address. So in the context of conserving IP address,
this should not be a big deal.

Jarrett


_______________________________________________
security-discuss mailing list
security-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]