[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen-2.0: privileged port connections
Kurt Garloff wrote: 1) ports < 1024 are reserved although 732 is currently unassignedNote 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 problemYes. 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 controlsudo, 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 consolesBefore 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 xfrdIt 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 desktopusers 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |