[[EMAIL PROTECTED] - Thu Jan 30 20:06:53 2003]: First of all apologies for mixing several problems in one post - i promise to do better next time, but i didn't consider the Rand-problems bugs and really just wanted to mention them on the side (having solved them for my purposes anyways) as a hint for others.
> > That's a bit coarse. It might be sufficient to allow the service to > interact with the desktop [interactive user] (as admin user, right > click on "My Computer", select Manage..., navigate to the services > section, right click on the indicated service, choose the "Log On" > tab, and under the radio button for "Local System account" there's > a checkbox (off by default): "Allow service to interact with > desktop". This can also be enabled when the service registers > itself at installation. > > See MS Knowledge Base article number 115825 (formerly Q115825), as > well as the documentation on ::CreateService() and search for > SERVICE_INTERACTIVE_PROCESS. > What's the use of allowing interaction with a pretty boring desktop which always looks the same and has no "Mouse action" for the purpose of generating randomness while introducing a security risk ? > > Of course some customer locations might be reticent about letting > services interact with the desktop, this being a potential security > hole. > > But is there a bug here? If it runs "okay" (with limited > functionality) if the service doesn't have permissions to access > the desktop, isn't that correct? What would you have it do > differently if it did detect that it was running as a service? Is > there some alternative source of randomness? (Perhaps the number > of patches applied to the system? :-). That would at least give us a high number... :-) The problem is the following: I was just compiling stunnel for use as service and had to get it running in a pretty short amount of time. Both calls (Rand_poll and RAND_file_name without a specified file) just had the effect that the service couldn't start up on system startup. You would only get a message that the system was unable to start up the service (for a million seconds or so), before giving up. I do not consider that a real bug, but it prevents usage of openSSL within such a service "out of the box". (It does not run "okay" then, otherwise i wouldn't have mentioned it) > > If so, it might be best to detect the problem at the specific API call > that fails rather than decide based on running as a service -- > partly because it might work running as a service, partly because > it might fail for other reasons when not running as a service. > I did not have the time to really dive deep into problems, so i was happy just being able to get everything running by just modifying Rand_poll and skipping the Rand_file_name call in stunnel. For Rand_poll i found it sufficient to leave out all stuff except for MS-randomness, epecially as the screen and user stuff doesn't seem to make much sense under the aforementioned circumstances anyways. If the number of system patches is considered in the MS-algorithm i can live with that randomness for the time being ;-) Not giving a Rand_file_name and skipping the function was o.k. for me too, as i don't have an "external" source of randomness on the systems i use stunnel on. If i have the time i'll try to come up with a good way to determine if beeing run as service, while i for myself can live with making that decision at compile-time at the moment. I'll also see if i can clarify the "rubbish" that comes up in filename after usage of Rand_file_name without filename and with no environment-variables set. The only thing i can say so far is that it definitely didn't even look slightly similar to something like ".rnd" (more like the encrypted binary version of the word "rubbish") I find it a bit tricky debugging a service at system startup without a remote debugger and leaving conditions realistic and original, but i'll see... Thanks a lot, best reagards, Claudius Thomas ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
