4

我需要一些有关更新某些 Windows 软件以与非存储 SCSI 设备通信的安全问题的帮助。

最初的软件是为 Windows XP 编写的 DLL，并通过 Adaptec 的 ASPI API 与设备通信。ASPI 没有任何安全性，因此任何用户运行的任何应用程序都可以使用我的 DLL 与这些设备之一进行通信，并且一切正常。

我现在正在使用 Microsoft 的现代 SPTI（SCSI Pass-Through Interface）API 更新软件以与 Windows 7 一起使用。在 XP 下使用 SPTI 一切正常，但 Windows 7 具有更严格的安全性，对于普通用户甚至管理员来说，SPTI 调用会返回一个错误，表明权限不足。如果我使用隐藏的“管理员”帐户登录，我的软件可以在 SPTI 上正常运行，但这不是可接受的部署选项。

以下是我迄今为止研究过的一些替代方案，以降低必须重写现有代码的水平：

  • 分离一个线程并提升其权限以伪装成“管理员”，以便它可以与 SPTI 对话。[我无法使用 LogonUser()/ImpersonateLoggedOnUser()/LoadUserProfile() 让它工作；对 LoadUserProfile() 的调用失败，SPTI 调用也因权限不足错误而失败。]
  • 编写一个具有足够权限与 SPTI 对话的 Windows 服务，然后让我的 DLL 与该服务对话。
  • 用户空间 (UMDF) 驱动程序。这将是一个昂贵的重写，我不清楚 UMDF 是否支持访问 SCSI 设备。
  • 内核 (KMDF) 驱动程序。应该可以工作，但会是一个更长、更昂贵的重写。

我希望这里的社区可以提供一些智慧/经验/想法，让我的代码在 Windows 7 下与这个 SCSI 设备对话，理想情况下不必重写太多。

4

1 回答 1

3

我将其作为答案提出，因为它太长了，无法发表评论。

我想您已经尝试设置应用程序的清单，以便它在运行时需要提升？重要的是要注意你必须提升一个进程，AFAIK你不能提升一个线程。

您建议将其作为服务运行然后与之通信（命名管道或 WCF 是可行的选项）是一个很好的建议。如果您将其作为本地系统运行，那么您的服务将比本地管理员拥有更多特权。

于 2012-09-08T04:57:39.730 回答