|
|
What are my options for securing a named pipe conversation so that only my client application can communicate with the Windows service server?
If I use a security descriptor, would that limit pipe access by user, or could it be used to limit pipe access to only my application?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
is there a reason you don't look for, and study, recent articles like this: [^]
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
I thank you for the reply.
Does this article give insight into how to secure the data passing over a named pipe so that only my application can read it?
I can say that the main reason I didn't look for that article is that it's not relevant to my question.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Message Closed
modified 4-Jan-23 4:59am.
|
|
|
|
|
I never said any of that. If this question is a waste of your time, then don't reply.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I assume that you will be using streams ... you could use the CryptoStream Class (System.Security.Cryptography) | Microsoft Learn[^] to encrypt & decrypt. If you google, you will find examples on how to do it if the MS examples are not enough.
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
Ahh! Thank you Graeme. That's the kind of pointer/tip I was looking for.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Cryptography secures what's "in the pipe"; it doesn't "secure the pipe". You're back to Access Control.
Named Pipe Security and Access Rights - Win32 apps | Microsoft Learn
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Very good point. Thank you. I am more interested in securing what's in the pipe. I want it so that even if someone can connect to the pipe, they won't be able to make sense of what's going back and forth.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
jschell wrote: Thread here suggests that more might be needed.
SSL is a CryptoStream.
What you don't have is authentication.
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
Hmmm,
You haven't really given enough information but I think you are wanting to:
- Have an application read/write over a named pipe.
- Prevent the application user from accessing the named pipe. (Essentially securing or isolating the information/pipe from the user)
If I were asked to do this I would use a DLL Surrogate and have the Custom Surrogate process open and manage the named pipe. This would allow you to have some security separation between the application users and surrogate process.
|
|
|
|
|
Your guess is spot on.
I'm glad you responded. Writing a native COM server might be slightly beyond my knowledge scope, but it probably depends upon exactly how secure I need the pipe's contents to be.
The information would be proprietary in nature, but it wouldn't be sensitive like personal user data.
I will consider this as a possibility. Thanks.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard,
It's much simpler than you can imagine. I can't think of any other way to accomplish your goal. What you are trying to achieve is less than 12 hours of work with a DLL surrogate. I can't remember off the top of my head if there were old code samples in the Windows SDK. I'm on a brand new workstation I built for Christmas so I don't even have my dev environment setup yet.
|
|
|
|
|
You could encrypt it yourself if you don't trust the framework.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I don't have any trouble trusting the framework to encrypt things. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I'm trying to be kind here, aight?
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yeah ... some of my data classes I binary serialize, then encrypt, then compress, then embed as resources. Make them work a little.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Smart, no-one would expect you to encrypt before compressing. 
|
|
|
|
|
Hey there,
Hope everyone is well.
I have a method in my Form1()
public void checkCommand(string command)
{
this.label1.Text = command;
}
I've written an external .dll class library with other methods, which I'm also using inside my main Form1(). But I do need to call a method/methods that are in my Form1() from this external .dll class library. However, I can't access it.
public class Commands
{
private string myCommand;
public void readCommand()
{
checkCommand(myCommand);
}
private void
}
Please note, I'll be using this external class library in multiple applications. So assigning Form1 inside my external dll is out of question, unfortunatelly.
Does anyone know the best solution to this, please?
I'll be very grateful for all your ideas. Thank you!
modified 29-Dec-22 17:20pm.
|
|
|
|
|
Question is not very clear.
C# has classes and methods (static or not.) You cannot access a method without the class.
Beyond that the class must also have a namespace.
So you must resolve the namespace. You must have a instance. You must call the method with that instance. Examples of all of that.
using SomeNamespace:
...
YourClass c = new YourClass();
c.checkCommand(myCommand);
To get to that class (as defined by the namespace) you must have the dll referenced in the binary build. Even to compile it it will need to be available. And of course delivered into an appropriate space (same file system directory) as the primary executable.
|
|
|
|
|
Thank you jschell. I appreciate your involvement.
Apologies, if perhaps I haven't made myself clear.
As per my post above, I've mentioned that I am using external dll. Therefore, I use namespace to it, exactly as per your suggestion. So in my Form1 I can access all methods from my external class library.
To be clear, this is an external dll class for my sockets client.
OnReceive(IAsyncResult ar) I need to display value on label.text in my Form1, or other forms where I will be using my external sockets class dll assembly.
Another method within that class need to call method from Form1 checkCommand(string command). Hope this will help explaining it better
Thank you again
|
|
|
|
|
There's a bunch of different ways of doing this, but NONE of them involve your class library calling a method in the form class.
Looking at your example code, I wouldn't even consider putting that code in the Form class, but instead in it's own class where you create an instead of it and pass that instance to your class library. Of course, that class will have to implement an interface your class library exposes and expects by an implementer.
|
|
|
|
|
You need to add an "interface" (e.g. IFormCommand) to your external dll that your form can implement; then you call into the dll with the interface ("sender" as IFormCommand); the dll can then use to interface to call the form's method(s); as defined in the interface.
You're basically trying to avoid a circular "using" reference (from dll to form) by using an interface (class).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
