C#:命名管道的完整性较低

发布于 2024-11-17 18:06:04 字数 2212 浏览 2 评论 0原文

我正在用 C# 开发 Internet Explorer 浏览器帮助对象 (BHO)。此 BHO 检测用户导航到的 URL,然后自动填充用户名和密码。

BHO 与作为服务运行的进程进行通信。通信通过命名管道进行。

当保护模式关闭时,通信工作正常。然而,当保护模式打开时,这不起作用。如果我以管理员身份运行 iexplore.exe 那么它就可以工作。

在保护模式下,我收到访问被拒绝的消息。

读完这篇文章后,我意识到管道访问被拒绝,因为 IE 正在运行 低完整性范围。

我已经阅读了以下文章 一个。了解 Internet Explorer 并在保护模式下工作 http://msdn.microsoft.com/en-us/library/bb250462.aspx

b.在创建管道资源之前还考虑了许多设置安全信息的建议,以允许较低完整性的进程使用它。然而这些对我来说并没有多大用处。 我仍然遇到同样的错误。

我目前唯一的解决办法是通过套接字进行通信。我验证了这个方法有效。

我更喜欢使用命名管道方法。

以下是我在打开管道之前设置安全上下文的源代码

服务端代码:

PipeSecurity security = new PipeSecurity();
security.AddAccessRule(new PipeAccessRule(
new SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, null),  // @"Users"
            PipeAccessRights.ReadWrite, 
            System.Security.AccessControl.AccessControlType.Allow
            ));

var currentUser = WindowsIdentity.GetCurrent().Name;
security.AddAccessRule(new PipeAccessRule(currentUser, PipeAccessRights.FullControl,   System.Security.AccessControl.AccessControlType.Allow));


NamedPipeServerStream stream;
stream = new NamedPipeServerStream(
            CommandPipeName,
            PipeDirection.InOut, MAX_PIPE_INSTANCE,
            PipeTransmissionMode.Message, PipeOptions.WriteThrough,
            EPHelperCommandPipeServerConsts.MaxPipeRequestLength,
            EPHelperCommandPipeServerConsts.MaxPipeResponseLength,
            security
            );

do
        {
            n++;

            isListening = true;
            stream.WaitForConnection();
            isListening = false;

            var cs = stream;

            stream = new NamedPipeServerStream(
                    CommandPipeName,
                    PipeDirection.InOut, MAX_PIPE_INSTANCE,
                    PipeTransmissionMode.Message, PipeOptions.WriteThrough,
                    EPHelperCommandPipeServerConsts.MaxPipeRequestLength,
                    EPHelperCommandPipeServerConsts.MaxPipeResponseLength,
                    security
                    );

    // some code

        } while (true);

我缺少什么吗?

谢谢。

I am developing an Internet Explorer Browser Helper Object (BHO) in C#. This BHO detects the URL that the user navigates to and then auto populates the username and password.

The BHO communicates with a process running as a service. The communication occurs over named pipes.

The communication works fine when protected mode is OFF. However when protected mode is ON this does not work. If I run iexplore.exe as adminsitrator then it works.

In protected mode I get the access denied message.

After reading about this I realize that the pipe access is denied because IE is running on
a low integrity scope.

I have gone through the following article
a. Understanding and Working in Protected Mode Internet Explorer
http://msdn.microsoft.com/en-us/library/bb250462.aspx

b.Also went through many suggestions of setting security info before creating the pipe resource to allow lower integrity process to use this. These however havent been of much use to me.
I still get the same error.

The only work around I have currently is to communicate over sockets. I verified that this approach works.

I would prefer to use the named pipe approach .

The following is my source code for setting the security context before opening the pipe

Service side code:

PipeSecurity security = new PipeSecurity();
security.AddAccessRule(new PipeAccessRule(
new SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, null),  // @"Users"
            PipeAccessRights.ReadWrite, 
            System.Security.AccessControl.AccessControlType.Allow
            ));

var currentUser = WindowsIdentity.GetCurrent().Name;
security.AddAccessRule(new PipeAccessRule(currentUser, PipeAccessRights.FullControl,   System.Security.AccessControl.AccessControlType.Allow));


NamedPipeServerStream stream;
stream = new NamedPipeServerStream(
            CommandPipeName,
            PipeDirection.InOut, MAX_PIPE_INSTANCE,
            PipeTransmissionMode.Message, PipeOptions.WriteThrough,
            EPHelperCommandPipeServerConsts.MaxPipeRequestLength,
            EPHelperCommandPipeServerConsts.MaxPipeResponseLength,
            security
            );

do
        {
            n++;

            isListening = true;
            stream.WaitForConnection();
            isListening = false;

            var cs = stream;

            stream = new NamedPipeServerStream(
                    CommandPipeName,
                    PipeDirection.InOut, MAX_PIPE_INSTANCE,
                    PipeTransmissionMode.Message, PipeOptions.WriteThrough,
                    EPHelperCommandPipeServerConsts.MaxPipeRequestLength,
                    EPHelperCommandPipeServerConsts.MaxPipeResponseLength,
                    security
                    );

    // some code

        } while (true);

Is there something that I am missing?

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

揽清风入怀 2024-11-24 18:06:04

我猜您可能与 Vista 中 Windows 添加的完整性级别机制发生冲突。该机制与基于访问控制列表中的允许和拒绝条目的访问控制机制正交。

在我看来,降低管道完整性级别的想法是正确的方法,但您的代码根本没有这样做。 .NET Framework 类尚不支持更改与资源关联的完整性标签。您必须使用 Win32 API。

请参阅我的博客上有关于我如何解决类似问题的描述 (替代网址):它可能会给你一些提示

I guess you are falling foul of the Integrity Level mechanism added to Windows in Vista. This mechanism is orthogonal to the access control mechanisms based on Allow and Deny entries in an Access Control List.

The idea of lowering the integrity level of the pipe sounds to me to be the correct approach, but your code doesn't do this at all. There is no support in the .NET Framework classes as yet for making changes to the Integrity Label associated with a resource. You have to work with the Win32 APIs.

See my blog for a description of how I solved a similar issue (alternative url): it may give you some pointers

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文