Hi Anthony,
On Wed, Mar 23, 2005 at 09:41:24AM -0600, Anthony Liguori wrote:
> So, here's my concerns:
>
> 1) ports < 1024 are reserved although 732 is currently unassigned
Note that NFS uses such ports without asking prior permission.
I chose 732 because it's unassigned indeed.
> 2) unix domain sockets would solve the same problem
Yes. There's one but:
With the patch you can currently configure xend from completely
open (xend-address '' and xend-privileged-port 0)
to closed (xend-address 'localhost' and xend-privileged-port 1)
except for root (and stuff I overlooked or did not do yet).
If you go for Unix Domain Sockets instead TCP, you lose the ability
of remote control. Unless you support both.
I did not investigate how difficult to do that would be.
If you have a patch, I'd volunteer to review :-)
> 3) this approach is not flexible for finer grain control
sudo, setuid, ... can provide that.
> 4) you still have to find a way to deal with the consoles
Before I start working on getting the consoles under control, I
wanted to see whether this approach is acceptable at all.
> 5) you still have to deal with xfrd
It seems to listen on *:8002 ...
Is there no authentication either? Sigh.
And we probably need to look into the event channel (8001) as well.
> With all that said, I'd like to see this applied as it's better than
> leaving everything out in the open.
For Xen-3.0, we may want to carefully chose what kind of backend (xend)
to frontend (xm) communication channels we want to allow and how
authentication and authorization is handled there.
But for Xen-2, let's try to find a pragmatic way that enables desktop
users to install and test xen without raising too many security
concerns.
Regards,
--
Kurt Garloff, Director SUSE Labs, Novell Inc.
pgpspivKNGCfb.pgp
Description: PGP signature
|
Home