SPTI/SCSI operations from a Windows 7 application

Question

I need some help regarding a security problem in updating some Windows software for communicating with a non-storage SCSI device.

The original software was written for Windows XP as a DLL, and talked with the device via Adaptec's ASPI API. ASPI didn't really have any security, so any application run by any user could use my DLL to talk to one of these devices, and everything worked great.

I'm now updating the software to work with Windows 7 using Microsoft's modern SPTI (SCSI Pass-Through Interface) API. Things work fine with SPTI under XP, but Windows 7 has much tighter security, and for normal users or even administrators, SPTI calls return an error indicating insufficient permissions. If I log in using the hidden "Administrator" account, my software runs fine with SPTI, but that's not an acceptable deployment option.

Here are some alternatives I've looked into so far, in order of decreasing level of having to rewrite existing code:

• Spinning off a thread and escalating its privileges to be pretend to be "Administrator" so it can talk with SPTI. [I haven't been able to get this to work using LogonUser()/ImpersonateLoggedOnUser()/LoadUserProfile(); the call to LoadUserProfile() fails, and SPTI calls fail as well with an insufficient permissions error.]
• Writing a Windows Service that has adequate permissions to talk with SPTI, and then having my DLL talk with that service.
• Userspace (UMDF) driver. It would be an expensive rewrite, and it's not clear to me whether UMDF supports accessing SCSI devices.
• Kernel (KMDF) driver. Should work, but would be a longer, more expensive rewrite.

I hope the community here can help with some wisdom/experience/ideas that will let my code talk to this SCSI device under Windows 7, ideally without having to rewrite too much.

Answer 1

I'm tendering this as an answer because it is bit too long to be a comment.

I presume you have tried setting the manifest of the application so that it requires elevation when it runs? It is important to note that you have to elevate a process, AFAIK you cannot elevate a thread.

Your suggestion of running it as a service and then communicating to that (a named pipe or WCF are viable options) is a good one. If you run it as Local System then your service will be more privileged than a local Administrator.