[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [RFC]: Secure migration



On Thu, Mar 05, 2009 at 09:58:46AM +0100, Daniel Veillard wrote:
> On Wed, Mar 04, 2009 at 11:03:17AM +0100, Chris Lalancette wrote:
> > > These are all just minor auth credentials/acl config tasks that the admin 
> > > has to deal with for normal remote usage already, so I don't see that they
> > > present a particular problem for migration
> > 
> > Yes, they are certainly all solvable from the admin's point-of-view, so they are
> > not show stoppers.  The thing is that I think admins will have a difficult time
> > discovering what the problems are when migration doesn't work for them.  There
> > are just so many combinations that it's very easy for the admin to get one of
> > them wrong, and then it may be difficult to figure out exactly what they need to
> > do to get it working.  On the other hand, having a dedicated channel makes it
> > relatively easy; if the admin is having problems, then the answer is going to be
> > "open port XYZ on the destination", and that will usually solve the problem.
> 
>   From my POV, I think getting the auth fixed is a matter of installing
> proper files on a machine and of the responsability of the sysadmins
> basically and purely within their realm. On the other hand opening a new
> port is a decision involving network admins and security, it's not the
> same scope within a company with strict policies.
>   I would really stay with the existing RPC model and avoid the
> requirement of adding a new open port, from a pure sysadmin "upgrade"
> perspective this can turn into a nightmare,

We've discussed this further on IRC and decided that if we need to get a
better authentication system for migration, then we should extend the
server RPC auth call to return a choice of multiple auth schemes. So,
for example, we could allow normal virsh cients to run SASL/TLS, and for
migration to run a one-time-key. The REMOTE_AUTH_LIST rpc command already
allows for this

  struct remote_auth_list_ret {
      remote_auth_type types<REMOTE_AUTH_TYPE_LIST_MAX>;
  };

we currently just always return a 1 element list. We can easily add more
auth options to the list without breaking existing clients too.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]