Sign in to follow this  
Followers 0
rbhkamal

Filter COM clients based on process path

9 posts in this topic

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


"When the power of love overcomes the love of power, the world will know peace"-Jimi Hendrix

Share this post


Link to post
Share on other sites



#3 ·  Posted (edited)

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 by Valik

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

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 by rbhkamal

"When the power of love overcomes the love of power, the world will know peace"-Jimi Hendrix

Share this post


Link to post
Share on other sites

#5 ·  Posted (edited)

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 by Valik

Share this post


Link to post
Share on other sites

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).


"When the power of love overcomes the love of power, the world will know peace"-Jimi Hendrix

Share this post


Link to post
Share on other sites

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?

:)


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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


"When the power of love overcomes the love of power, the world will know peace"-Jimi Hendrix

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0