From: Max A. F. <ma...@co...> - 2009-03-22 19:22:39
|
> -----Original Message----- > From: Wouter Vermaelen [mailto:wou...@sc...] > Sent: Sunday, March 22, 2009 1:22 > To: ma...@co... > Cc: 'openmsx-devel' > Subject: Re: Heading towards a release? > > > My main TODO at the moment is to integrate the Windows socket security work > > that we discussed earlier. However, I'm still pending an ACK from you that > > this is work that you want to see included in openMSX. > > Ah, I'm sorry if my last mail about this wasn't clear: > The prototype so far looks reasonable. Though it's not a full solution yet > (actual authorization and rendez-vous part is missing). No, I heard that. Maybe my last email was lost? ========= I've updated the code to do proper authorization. I also got it to work on a Kerberos network as well as an NTLM network. http://mfeingol.almonaster.net/downloads/openmsx-vc/ClientServer.zip It still needs cleanup, as well as adaptation to openMSX styles. But this is more or less what to expect. ========= Concerning rendezvous, I think we need to do some design first - agree on requirements and then pick either a cross-platform solution or solid platform-specific solutions. We can keep the existing method for this release. > And it would also be nice to have a prototype of a python client. It already exists, in pywin32. Look under win32\Demos\security\sspi: simple_auth.py and socket_server.py have largely the same kind of exercise as my Win32 C code. > It's a bit sad that the code is more complex than the unix side (though it's > not that bad at all). But I trust your judgement that this is a good approach > to achieve the security requirements on windows. So I really like to see this > included in openMSX. Great. And yes, SSPI code isn't pretty, but it's the right way to secure an open channel on Windows. > I leave the decision to include it in this release or in some later release > completely up to you. (It's not a regression so releasing without it is not > a problem. Including it in a release breaks backwardscompatibilty, but for > good reasons). I think I'd like to do it in this release and get it out there as soon as possible. I'll look into the existing sockets code and see how best to integrate it. My current intuition is to create virtual authn/authz base classes, then create a no-op set and an SSPI-based set for now. We can then extend this over time to include username/password or whatever we need for authenticated cross-platform communication. > If we do include it, we should of course also update the > catapult and openmsx-debugger clients. Absolutely. And like other things, at the moment this is going to lead to some code duplication through the three projects. > Why should this be optional? Does it depend on extra libs? It depends on secur32.dll, but that's on every version of Windows. > And IMHO from a > security pov, if it's implemented well, there is no reason to disable it (it > doesn't give an attacker more privileges than he already has). I agree. My concern was largely that I'd be breaking compatibility with people doing semi-exotic things with these endpoints, but it's probably better that we hear about it and incorporate the scenarios than people be insecure. |