“Attempted to perform an unauthorized operation” when calling NamedPipeServerStream.SetAccessControl

[TylerLeonhardt]

I'm having some trouble securing a NamedPipeServerStream from a .NET Standard lib. I opened a question on stack overflow here.

The gist is that when I try to call SetAccessControl using either of the listed ways, I get an "Attempted to perform an unauthorized operation":

• PipesAclExtensions.SetAccessControl(pipeServer, pipeSecurity);
• pipeServer.SetAccessControl(pipeSecurity);

Here's a gist of the problem.

PipeSecurity pipeSecurity = new PipeSecurity();

WindowsIdentity identity = WindowsIdentity.GetCurrent();
WindowsPrincipal principal = new WindowsPrincipal(identity);

if (principal.IsInRole(WindowsBuiltInRole.Administrator))
{
    // Allow the Administrators group full access to the pipe.
    pipeSecurity.AddAccessRule(new PipeAccessRule(
        new SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid, null).Translate(typeof(NTAccount)),
        PipeAccessRights.FullControl, AccessControlType.Allow));
} else {
    // Allow AuthenticatedUser read and write access to the pipe.
    pipeSecurity.AddAccessRule(new PipeAccessRule(
        WindowsIdentity.GetCurrent().User,
        PipeAccessRights.ReadWrite, AccessControlType.Allow));
}

var pipeServer =
    new NamedPipeServerStream(
        "mypipe",
        PipeDirection.InOut,
        1,
        PipeTransmissionMode.Byte,
        PipeOptions.Asynchronous);

// Both of these throw
PipesAclExtensions.SetAccessControl(pipeServer, pipeSecurity);
// or
pipeServer.SetAccessControl(pipeSecurity);

The exception I'm getting is:

Attempted to perform an unauthorized operation.
at System.Security.AccessControl.Win32.SetSecurityInfo(ResourceType type, String name, SafeHandle handle, SecurityInfos securityInformation, SecurityIdentifier owner, SecurityIdentifier group, GenericAcl sacl, GenericAcl dacl)
at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, SafeHandle handle, AccessControlSections includeSections, Object exceptionContext)
at System.Security.AccessControl.NativeObjectSecurity.Persist(SafeHandle handle, AccessControlSections includeSections, Object exceptionContext)
at System.IO.Pipes.PipeSecurity.Persist(SafeHandle handle)

NOTE: I am pulling in the System.IO.Pipes.AccessControl nuget package

Am I doing something wrong?

[TylerLeonhardt]

I noticed that the tests for the extension methods all use the empty PipeSecurity() constructor so I tried using an empty one in my code to see if this could be a bug that was overlooked since the tests never added an access rule.

Sure enough, if I pass in an empty PipeSecurity into SetAccessControl, my code works:

PipesAclExtensions.SetAccessControl(pipeServer, new PipeSecurity());

From what I know about Named Pipes, when you create them, you can pass in a Security object that will create all the ACLs you want but you can't update them once created. This means that SetAccessControl probably won't work for NamedPipes.

In the .NET Framework, there was a ctor for NamePipeServerStream that allowed you to pass in a PipeSecurity but that doesn't seem to exist in .NET Core (probably because everything is split up now).

I'm really hoping there's some sort of solution for this out in the wild as I need it in .NET Core 2.0 - otherwise I'll have to go down the pinvoke route to create a Pipe that way.

[feco93]

A think the main reason is that the ACLs feature currently not implemented in UNIX variant NamedPipeServer implementation.

This SO post also about this problem:
https://stackoverflow.com/questions/50500488/securing-namedpipeserverstream-on-unix

I also hope this feature will be implemented in the near future.

[TylerLeonhardt]

I appreciate the response but the limitation I pointed out is on Windows which I would expect to work with Pipe Security.

Unix is important as well, but that to me is an additional feature, not a bug like this issue is :)

[danmoseley]

@pjanotti @weshaggard do you know why NamedPipeServerSTream is missing the ACL overloads like NamedPipeServerStream(string pipeName, PipeDirection direction, int maxNumberOfServerInstances, PipeTransmissionMode transmissionMode, PipeOptions options, int inBufferSize, int outBufferSize, PipeSecurity pipeSecurity, HandleInheritability inheritability, PipeAccessRights additionalAccessRights) ? I assumed it was because ACL could not be referenced (cycle) but it is already referenced by this library.

[weshaggard]

@danmosemsft your correct that it wasn't included because of layering issues. NamedPipeServerStream is part of .NET Standard but the ACL API's are not so this member was excluded from the standard and here in the core.

[danmoseley]

Talked offline, part of the problem is that ACL's are not even part of the base shared package so having NPSS reference ACL's pulls a lot of code into the core install.

@pjanotti hopefully can help brainstorm possible solutions for what you want to do.

[pjanotti]

Hi @tylerl0706 - Windows docs state that should be possible, but I gave a few tries and couldn't do it too - I'll have to investigate it more. Is the new feature CurrentUserOnly a possible workaround for your scenario?

[pjanotti]

@tylerl0706 you won't be able to do without p/invoke since you need to specify something like WRITE_DAC when creating the named pipe (see here, search for WRITE_DAC).

@danmosemsft I am getting under the impression that System.IO.Pipes.AccessControl never worked with anything other than an empty PipeSecurity ... do you remember any history in this regard?

The feature request to support WRITE_DAC is already opened, see #23554.

[danmoseley]

@pjanotti I don't know. The original commit suggests PipeSecurity is expected to work. Hopefully you can figure out the history and missing pieces.

[pjanotti]

Looking at the history it should never worked since the rights flags were never set when calling CreateNamedPipe (since 1st version on the repo).

[pjanotti]

One possible way to make this work is to add to S.IO.Pipes.AccessControl some static factory methods that can create named pipes with PipeSecurity and PipeAccessRights equivalent to the constructors that are in the Fx but not in the standard - this will allow the same old functionality of the Fx. There should be some refactor to avoid/reduce code duplication but in principle I don't see a reason for it not to work.

OTOH S.IO.Pipes.AccessControl seems to never ever actually worked with anything other than the empty PipeSecurity and since this is the first time that we are realizing that I'm questioning if it is worth to fix... likely we can't just drop the package for compat reasons: there seems to be a number of projects referencing it but I can't see any useful usage of it as it is.

@tylerl0706 if you can provide some more info about your scenario and what you are trying to achieve? It can be a helpful data point.

/cc @danmosemsft @stephentoub @weshaggard @safern

[pjanotti]

The constructors that are related to AccessControl and could be covered in the package for matching functionality with Fx are:

namespace System.IO.Pipes
{
    public sealed class AnonymousPipeServerStream : PipeStream
    {
        public AnonymousPipeServerStream(PipeDirection direction, HandleInheritability inheritability, int bufferSize, PipeSecurity pipeSecurity);
    }

    public sealed class NamedPipeClientStream : PipeStream
    {
        public NamedPipeClientStream(string serverName, string pipeName, PipeAccessRights desiredAccessRights, PipeOptions options, TokenImpersonationLevel impersonationLevel, HandleInheritability inheritability);
    }

    public sealed class NamedPipeServerStream : PipeStream
    {
        public NamedPipeServerStream(string pipeName, PipeDirection direction, int maxNumberOfServerInstances, PipeTransmissionMode transmissionMode, PipeOptions options, int inBufferSize, int outBufferSize, PipeSecurity pipeSecurity);
        public NamedPipeServerStream(string pipeName, PipeDirection direction, int maxNumberOfServerInstances, PipeTransmissionMode transmissionMode, PipeOptions options, int inBufferSize, int outBufferSize, PipeSecurity pipeSecurity, HandleInheritability inheritability);
        public NamedPipeServerStream(string pipeName, PipeDirection direction, int maxNumberOfServerInstances, PipeTransmissionMode transmissionMode, PipeOptions options, int inBufferSize, int outBufferSize, PipeSecurity pipeSecurity, HandleInheritability inheritability, PipeAccessRights additionalAccessRights);
    }
}

Note that only one of them shows some usage in apisof.net: 0.10 of nuget packages for NamedPipeServerStream..ctor(String,PipeDirection,Int32,PipeTransmissionMode,PipeOptions,Int32,Int32,PipeSecurity,HandleInheritability).

[TylerLeonhardt]

I ended up going the p/invoke route and borrowed most of the code from PowerShell...
https://github.com/PowerShell/PowerShellEditorServices/blob/1031e2296449ab30bb4968e0285566a33e4bf9f4/src/PowerShellEditorServices.Protocol/MessageProtocol/Channel/NamedPipeServerListener.cs#L136-L274

It's ugly... But at least our pipes are secure. -CurrentUser would do the trick... But I have to support back to .NET Core 2.0.

[pjanotti]

Thanks for reporting back. I am under the impression that CurrentUserOnly should satisfy most needs in this regard... but we may get more people asking for this as they migrate from Fx to CoreFx.

[danmoseley]

@tylerl0706 as you probably know 2.0 will go out of support in 2 1/2 months - Oct 1st so perhaps you can move to CurrentUserOnly at that point?