Jian-Xiang Alex Peng wrote: > Darren Reed ??: > >> 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. > > > > The global zone administrator can do this: > > bash-3.00# zlogin ex-1 ipf -f - > pass in all > bash-3.00# zlogin ex-1 ipfstat -io > empty list for ipfilter(out) > pass in all > bash-3.00# zlogin ex-1 ipf -f - > pass out all > bash-3.00# zlogin ex-1 ipfstat -io > pass out all > pass in all > bash-3.00# ipfstat -io > empty list for ipfilter(out) > empty list for ipfilter(in) > > > He can change/touch the local exclusive zone's ipf rule. But here > "zlogin" is the key to get into the local zone, this should not be > the solution to your original question.
Sure, but if you give root access to someone else who "owns" the local zone then they can change your rules. Not good. Darren
