Jian-Xiang Alex Peng wrote: > Darren Reed wrote: > >> An issue with the design I brought up with Yukun, before I left >> China, that doesn't seem to have been addressed in the current >> code is that it is not possible to selectively apply the global >> zone filtering policy to zones with an exclusive stack instance. >> >> As it stands we currently have two scenarios with SI: >> 1) shared stack instances where filtering is done in the global >> zone >> 2) exclusive stack instances where filtering is done "in" the >> local zone >> >> With (2) it is not possible for the administrator of a machine to >> specify a machine policy whilst delegating network control to >> a local zone. I'd consider this a serious design flaw that needs >> to be fixed with a knob that is either on or off for each stack >> instance that tells IPFilter whether or not to run the global >> zone policy before/after the local zone policy. Running the >> global zone policy before/after the local zone policy isn't >> something that everyone will want to do, but I'll put money on >> it being high on the wanted list very quickly if you leave it out. >> >> What needs to happen for exclusive stack instances is: >> packet inbound --> global zone policy? --> local zone policy --> kernel >> packet outbound --> local zone policy --> global zone policy? --> nic >> >> Darren > > > > Perhaps similar scenario comes with IPsec: > packet inbound --> global zone IPsec policy? --> local zone IPsec > policy --> kernel > packet outbound --> local zone IPsec policy --> global zone IPsec > policy? --> nic > > > Or the "exclusive" here only means - the global zone administrator > should only cares the resources the exclusive zone needs, e.g. > zonepath, NICs, etc. The other administration tasks should be done > by local zone administrator, e.g. ipfilter, ipsec policy. > > Which model is much clearer?
The problem isn't as critical with IPsec but could still exist there too. What you're missing here is that the global zone administrator is relinquishing his ability to control network access of the local zone when configuring it with an exclusive stack instance. The physical machine within which all of the zones exist is a perimeter of sorts and to not allow the global zone admin to control IPFilter/IPsec for exclusive stack instances is to carve out part of the perimeter from the administrator's control. It shouldn't be like that. An administrator should be able to choose whether or not a local zone with an exclusive stack instance has unfetted access to the outside world or not. It is as simple as that. There should be two layers of policy available here: - one for the machine - one for the exclusive stack instance Maybe both don't need to be present all the time, but it should be possible to have both applied if desired. Saying that it is upto the local zone to configure the IPFilter policy ignores the possibility of the local zone administration being potentially at odds with the desires of the global zone administration. I, as a global zone administrator, should be able to specify a policy statement such as "no access to samba services" and be able to implement that from the global zone whilst at the same time giving root access to other zones with exclusive stacks without fear of that access policy being violated. Darren
