← Back to team overview

openstack team mailing list archive

Re: Nova root wrapper understanding

 

Thanks, Thierry Carrez. Your explanation is easy to understand. I have got
why we need such a mechanism.

BTW, is root-wrap a general or popular way to keep security? I have no
experience on security, but I have heard the *root *should be banned
because of security. Ideally, should we ban *root *in nodes and just use
root wrapped *nova *user for tasks in need?


On Fri, Jan 11, 2013 at 7:29 PM, Thierry Carrez <thierry@xxxxxxxxxxxxx>wrote:

> Daniel P. Berrange wrote:
> > FWIW, if you've got libguestfs available, the file injection code does
> > not require any rootwrap usage. Ironically the config drive stuff now
> > does require root if you configure it to use FAT instead of ISO9660 :-(
>
> My issue is that we enable a very permissive compute.filters just to
> care for the case where you use localfs-style injection. We generally
> hurt the security model to care for a specific less-secure deploy option.
>
> What we /could/ do is split compute.filters so that you have a specific
> filters file for localfs-style injection commands. Deployers would
> enable that specific file in the case they use localfs-style injection.
>
> It's tricky because you can't really trust nova to tell you which option
> it runs with, so you have to rely on deployers enabling the
> localfs-option to also enable that specific filters file, which is a bit
> of a configuration nightmare and very error-prone.
>
> Alternatively we could rip out localfs-style injection altogether.
>
> > I have a general desire to make it such that you can run with KVM and
> > Nova without requiring rootwrap for anything. last time I looked the
> > three general areas where we required root wrap were networking, storage
> > and file injection. My recent refactoring of file injection addressed
> > the latter by using libguestfs APIs instead of libguestfs FUSE.
> Networking
> > is mostly solved if using newest libvirt + Quantum instead of Nova's
> > own networking. Storage is something that cna be addressed by using
> > libvirt's storage APIs instead of running commands directly.
>
> That's my goal too. Ideally devs would think twice before adding any new
> run_as_root=True command. Every command we add lowers the security model
> around openstack. It's very easy to add one, and very difficult to
> remove one once it's in.
>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

Follow ups

References