Open Stack

On Thu, 2020-03-19 at 18:24 -0500, Ben Nemec wrote:
> 
> On 3/19/20 5:22 PM, Sean Mooney wrote:
> > On Thu, 2020-03-19 at 16:04 +0000, Sean Mooney wrote:
> > > On Thu, 2020-03-19 at 16:50 +0100, Iury Gregory wrote:
> > > > Hi Rodolfo,
> > > > 
> > > > Thanks for raising this topic. I like the idea and I can work in the ironic
> > > > part.
> > > > 
> > > > Em qui., 19 de mar. de 2020 às 16:47, Rodolfo Alonso <ralonsoh at redhat.com>
> > > > escreveu:
> > > > 
> > > > > Hello all:
> > > > > 
> > > > > With this mail I would like to propose the goal to move away from
> > > > > oslo.rootwrap and migrate to
> > > > > oslo.privsep. The last one offers a superior security model, faster and
> > > > > more secure. During the last
> > > > > cycles and since privsep was released, the Community has encouraged the
> > > > > usage of privsep and the
> > > > > deprecation of any existing code still using rootwrap.
> > 
> > i had a rather long rant about why privsep is only more secure if you use it correctly
> > i would say that today most project that use privsep are not as secure as you think they
> > are or as secure as you would like them to be.
> > 
> > i would say that the privsep guide also is not entirely correct as it advocate
> > groping privileged function in a singel module  and gives an example of a context that
> > has two many capabilities.
> > 
> > we have the unfortunate situation that in nova and neuton a singel privsep context is used
> > for all privadge function meaning it has the some of all posible capablites that any code
> > path can require.  that is an anti pattern. also we group privaldage funcition
> > in a <project?>/privsep/... module which encurages function reuse which encurages widing the
> > contract to make them more resuable which again is an anti patteren.
> 
> Wasn't there a reason for them to all be in one module though? Like a 
> hacking check to verify that privileged functions were used safely?
> 
> You're right about widening the contract for reuse being bad, but it 
> seems to me that could happen wherever the code lives. A lot of the 
> problems with the Nova implementation are that it is (or at least was) a 
> straight port of the rootwrap calls, so in some ways it just exposed the 
> insecurity of the rootwrap design too.
> 
> > 
> > this lead to function like nova.privsep.path.writefile(path, mode, data).
> > which litally allows you to write to any file on the system with any mod and put any data.
> > that breaks all the rules. first it has a wide contract by takeing both the path and mode.
> > second its not got _privaladged in the fucntion name so we have to have a hacking check to prevent
> > you doing "from nova.privsep import fs; ...  fs.writefile(...)" without realising its privaldaged.
> 
> Ah, this is what I was thinking of.
actully i think what you were thinking of was the prefix
https://github.com/openstack/nova/blob/master/nova/privsep/__init__.py#L22
which is used in the entrypoint decorator

https://github.com/openstack/oslo.privsep/blob/e896ed39c4b2d8492bb91283d99c6446bacc657c/oslo_privsep/priv_context.py#L217
to ensure that the decorate can not be used out side of the module or sub module where the context is defiend.

so in the nova case we do 
sys_admin_pctxt = priv_context.PrivContext(
    'nova',
    cfg_section='nova_sys_admin',
    pypath=__name__ + '.sys_admin_pctxt',
    capabilities=[capabilities.CAP_CHOWN,
                  capabilities.CAP_DAC_OVERRIDE,
                  capabilities.CAP_DAC_READ_SEARCH,
                  capabilities.CAP_FOWNER,
                  capabilities.CAP_NET_ADMIN,
                  capabilities.CAP_SYS_ADMIN],
)

and teh first parmater 'nova'
ensure that any function that use the decorator must be part of nova

e.g. this will not work
--- ~/my_project/my_module.py---

from nova import privsep
@privsep.sys_admin_pctxt.entrypoint
def my_func():
   print("hi")

in nova we technically could use 'nova.privsep' to prevent any
other moduel in nova form containg privladged funcitons based on that context.

in the os-vif ovs plugin we do

vif_plug = priv_context.PrivContext(
    "vif_plug_ovs",
    cfg_section="vif_plug_ovs_privileged",
    pypath=__name__ + ".vif_plug",
    capabilities=[c.CAP_NET_ADMIN],
)

so in the linxu bridge plugin you could not incorrectly use the ovs context because they are not in the same submodule.

>  I guess you either use a naming 
> convention for all privileged functions or put them in a single/few 
> modules that you can run hacking checks on. I've meant to see if we 
> could pull the Nova hacking check into privsep so other projects could 
> use it.
> 
> Either approach has its benefits and drawbacks. We could probably 
> mention both in the privsep user docs and just say that projects should 
> be consistent in which they use.
line lenght/typing is the main drawback for the suffix/nameing convention but yes both approchs
work i obviously have a bias to the one i prefer but since i have not gone through and change all of os-vif
to follow the suffix approch i dont think its worth needless code change just to conform to it.
> 
> > thrid its grouped in privsep module with encurage it to be used form may part of the code base require
> > int the wide contract, and finally becasue nova only has one privsep context
> >   capabilities=[capabilities.CAP_CHOWN,
> >                    capabilities.CAP_DAC_OVERRIDE,
> >                    capabilities.CAP_DAC_READ_SEARCH,
> >                    capabilities.CAP_FOWNER,
> >                    capabilities.CAP_NET_ADMIN,
> >                    capabilities.CAP_SYS_ADMIN],
> > 
> > instead of just the file capablies it also has cap_net_admin and cap_sys_admin  so it can mess
> > with sysfs and so other thing that would normaly be prevented if it only had the capablites required
> > for the specalised fucntion it callse writefile. for exampel create a vm conosle log....
> > 
> > this has come up in the past on the mainlist and at at least two ptgs
> > http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004358.html
> 
> Yeah, I think it has been acknowledged that the Nova use of privsep is 
> not ideal. I do want to note that the use of general-purpose privileged 
> functions like writefile is specifically discouraged in multiple places 
> in the privsep docs. That was a lesson learned from the initial Nova 
> migration.
> 
> I believe privsep already supports multiple contexts, so maybe the docs 
> need to be expanded to include that as a best practice.
ya you can. os-vif is always using two contexts.
we have 1 context per plugin an one for the root of the libary.

strictly speakign you dont need to do that but we wanted to use the in tree plugins as a template for creating your own
and in general each plug should have its own security context but normally you would only have muliple contexts if you
they had differnet capabliies.
since each context mean an addtional unix socket and demon you don twant to have hundres of them
but nova should proably have 3 looking at the set of capablites ie uses.

to use multiple context after they are defiend you just need to use the correct decorator so
its really easy to work with.
>