Kurt Garloff wrote:
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.
With all due respect to the NFS folks, NFS is just not
a good example to follow in any aspect. Just picking an
unassigned port randomly won't ensure a non-conflict.
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 :-)
Yes, we can do this, allow users to select which protocol
they want. But picking one solution and resolving it's
deficiencies in other ways would be simpler and cleaner
in the long run. Having the user make fewer infrastructure
decisions like this, the better. It also becomes an issue
when the distros need to ship with a fixed config.
3) this approach is not flexible for finer grain control
sudo, setuid, ... can provide that.
The fewer such programs, the better for security, right?
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.
Yep.
With all that said, I'd like to see this applied as it's better than
leaving everything out in the open.
Agreed.
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.
Agreed.
thanks,
Nivedita
-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
| 
Home