Open Stack

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. 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.

> 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.