Filter COM clients based on process path

[rbhkamal]

I'm creating my first COM service ever using this (http://www.codeguru.com/cpp/com-tech/activex/tutorials/article.php/c5567) which is great. But I need to know if there is anyway for the COM service to get the process path of the COM clients.

So for example:

c:\client-au3-testing-*.exe is allowed access

everything else is blocked.

The next step is to verify the executables signature but that would be easy once I have the process path.

Thanks (its been a while)

RK

[danielkza]

Have you tried GetModuleFileName?

[Valik]

COM is not the solution for whatever problem you are trying to solve. What is the problem you are trying to solve? Using path based restrictions on what can or cannot access a resource seems rather arbitrary.

Edit: I should re-phrase. I can't accurately say "COM is not the solution for whatever problem you are trying to solve" without knowing what the real problem is. What I really mean is that COM makes no sense in the situation you describe. If you wish to limit what can use the object(s), then using a technology like COM is over-engineering at best.

Edited February 20, 2011 by Valik

[rbhkamal]

COM is not the solution for whatever problem you are trying to solve. What is the problem you are trying to solve? Using path based restrictions on what can or cannot access a resource seems rather arbitrary.

Edit: I should re-phrase. I can't accurately say "COM is not the solution for whatever problem you are trying to solve" without knowing what the real problem is. What I really mean is that COM makes no sense in the situation you describe. If you wish to limit what can use the object(s), then using a technology like COM is over-engineering at best.

I agree with you 100%.... I really didn't want to open this can of worms but here we go..

[DELETED]

[DELETED]

So now I'm forced to modify the code for the COM service to do one of the following:

1- Accept calls *only* from processes running from my installation folder (protected using the filter)

2- Protect the IPC with a shared secret (somehow)

I'm trying number 1

Edited February 20, 2011 by rbhkamal

[Valik]

The COM service is being installed on a secure system where every user has full administrator permissions (but can't go to safe-mode)

This statement contains a contradiction. If the systems were secure this would be a non-issue. The systems are not secure because users have administrative rights.

Why do users have administrative rights? If users must have administrative rights (they shouldn't), why aren't SE_BACKUP_NAME and SE_RESTORE_NAME being stripped to prevent them from reading/taking ownership over other user's files? Create a custom "Administrators-Lite" group with all the privileges of the Administrators group except those two and voila, administrators (mostly) without the ability to read/write/take over files they don't own. In other words, removing these two privileges puts things back into the hands of the ACL which is your entire problem in the first place (Assuming the files in question are stored correctly in a location with the correct folder permissions set).

and there is a risk that some users might want to steal other user's virtual harddrives (.vdi).

This is the second problem. Why is this an issue? If the contents of the drives are so important then the drives should be encrypted so that even if another user gets of one of the files and attaches it to their VM they will only see the operating system stuff. All important data should be on a separate encrypted partition or virtual drive.

Too long; didn't read version: You have security issues and didn't do your homework to solve them. You are over-engineering solutions that will never cover all cases to fix basic security issues. Rule #1, users are not administrators. Fix that and fix everything. If you cannot stop using administrative accounts (then you need to re-design the system form scratch, but I digress) then strip undesirable privileges from users. Better yet, selectively grant them only the privileges that are causing the administrators account requirement in the first place.

Edited February 20, 2011 by Valik

[rbhkamal]

But my very simply question still stands, is there any way for a COM service to get the path of the callers process? How?

Valik, even though I would love to spill my guts here, there are some details that I cannot disscus here so please understand. In my case, path-based protection is the fastest and the most secure (and its not up to me anyway).

[PsaltyDS]

As others already posted, I don't see the point in what you're doing, but...

If you get the calling process id, then you can get the execution path of that process. There is a WMI process inside _ProcessListProperties() (in Example Scripts), and you can do it by DLL calls too. That changes the question to whether you have the PID of the calling process?

[Valik]

In my case, path-based protection is the fastest and the most secure (and its not up to me anyway).

Then tell your idiot handlers that your method isn't secure, isn't remotely close to being secure, is a bad idea and will not achieve their goals and that they need to try using real security.

Please try to understand that.

[rbhkamal]

Then tell your idiot handlers that your method isn't secure, isn't remotely close to being secure, is a bad idea and will not achieve their goals and that they need to try using real security.

Please try to understand that.

Right