DLL Wrapper (I Think?)
in [Visual Basic]
|
Prev: WMI to use or not to use
Next: VB6 on Windows 7 64-Bit
From: David on 9 Jan 2010 11:19 Ralph: Have VC++ 6.0. However, have to disagree. Knowing C++ and manipulating various OS security settings and other settings are two VERY different things. Writing code requires a knowledge of the specific language syntax and learning which API calls are needed to accomplish your objective. The OS on the otherhand requires you to understand how MS put all this together and its inter-relationship (what affects what). This is where I encounter most of my problems, as either to much or too little documentation (especially if you don't know what to look for to solve the problem). "Ralph" <nt_consulting64(a)yahoo.com> wrote in message news:uL0h4NUkKHA.4772(a)TK2MSFTNGP04.phx.gbl... > Ralph wrote: > >> [Now if anyone feels like flaming me for evangelizing VC. Don't >> botter. I'm guility.] > > Or "bother". <g> > > -ralph > >
From: Nobody on 9 Jan 2010 11:53 "Ralph" <nt_consulting64(a)yahoo.com> wrote in message news:eOH6uJUkKHA.3792(a)TK2MSFTNGP02.phx.gbl... > David wrote: >> >> I'm starting to get outside my confort zone (need to climb the >> learning curve on DCOM and OS Security) >> >> Any good books or suggestions on "easiest" way to learn this? I can't see David's post quoted above. Must have been lost in cyber space. Here is Google copy which doesn't include it: http://groups.google.com/group/microsoft.public.vb.general.discussion/browse_thread/thread/46ebc61070174321/9f935c6a8051524b
From: Nobody on 9 Jan 2010 13:35 "David" <dw85745NOT(a)earthlink.net> wrote in message news:ekr$kvTkKHA.4912(a)TK2MSFTNGP02.phx.gbl... > OK. Found this which helps: > > Article ID: 268550 - Last Review: July 15, 2004 - Revision: 1.2 > How To Use Dcomcnfg for a Visual Basic DCOM Client/Server Application Basically, in "Security" tab of the component, you disable Remote Launch and Activation permissions. The users who you see there are allowed to load the component. The component could start as a different user, and you can do that by using the "Identity" tab. In this case, Windows starts the component using the user that you specify, even if that user has higher privileges than the user who launched it. This can be used in situations where you want a standard user to do administrative things, for example. In your place, I would do it the following way: - Use DCOM tool to disable Remote Launch and Activation for all listed users. You don't need to change anything in Identity tab. - Create a special user using the application name as the name of the user. Lets call this VBUser. This user should have no groups assigned to it. - Use Windows Explorer to allow this user permissions for Read&Execute to critical system folders, such as "C:\Windows" and "C:\Program Files". Do not change the permissions on "Documents and Settings". Windows does that for you. There are probably other places to add this user to, like in User Rights Assignment in Local Security Policy, but the simplest solution is to make this user a member of the Users group. - Make a Start.exe that calls CreateProcessWithLogonW(). Use LOGON_WITH_PROFILE flag. However, to save time, you may want to first create a shortcut to your app, and use the shortcut Advanced button to run your app as a different user. I think Windows only allows you to use accounts that don't have blank passwords. If you need to run your app as SYSTEM, you can't use this method, and instead, create a task in Task Scheduler(time doesn't matter), specify SYSTEM as the user name and leave the password blank. Disable the task, then when you want to run it, right click it and select Run. The above so far locks the DLL(and your process) from accessing files outside the folder that you configured. The DLL can still read the contents of the OS folders above. The DLL can still access other applications running on the same desktop or terminal session as the logged on user by sending messages. However, in Vista+, if the logged on user has higher privileges than VBUser, the messages are blocked. In XP/2003 Server and below, messages are not blocked even when using different accounts. The only thing that is blocked between different accounts in Windows 2000+ are hooks, such as by SetWindowsHookEx. If you want to block messages in 2000/XP/2003, then you have to use Jobs. In this case, when calling CreateProcessWithLogonW(), specify CREATE_SUSPENDED flag, and call CreateJobObject/AssignProcessToJobObject, followed by ResumeThread(). This works in Vista+ too.
From: Ralph on 9 Jan 2010 13:50 "David" <dw85745NOT(a)earthlink.net> wrote in message news:%23nE8AeUkKHA.5020(a)TK2MSFTNGP02.phx.gbl... > Ralph: > > Have VC++ 6.0. > > However, have to disagree. Knowing C++ and manipulating various OS security > settings and other settings are two VERY different things. > Agree. Programming Languages and Operating Systems are two different things. > Writing code requires a knowledge of the specific language syntax and > learning which API calls are needed to accomplish your objective. > True. > The OS on the otherhand requires you to understand how MS put all this > together and its inter-relationship (what affects what). This is where I > encounter most of my problems, as either to much or too little documentation > (especially if you don't know what to look for to solve the problem). > Again. I would agree. Many of the best Admininstrators and System operators I have known have been lousy programmers if not essentially illiterate outside scripting languages (and here they tend to be experts). However, from a Programmers perspective, you will always need to go deeper, and deeper means C/C++. You have presented excellent reasons to ignore my advice to learn C/C++. -ralph
From: David on 10 Jan 2010 00:32
Nobody: Can't thank you enough for all the effort on my behalf. .. Will take me a day or two to "digest" all the great info provided. Will repost this thread when done and/or if additional questions. Have a nice day. David "Nobody" <nobody(a)nobody.com> wrote in message news:eAl9MqVkKHA.1536(a)TK2MSFTNGP06.phx.gbl... > "David" <dw85745NOT(a)earthlink.net> wrote in message > news:ekr$kvTkKHA.4912(a)TK2MSFTNGP02.phx.gbl... >> OK. Found this which helps: >> >> Article ID: 268550 - Last Review: July 15, 2004 - Revision: 1.2 >> How To Use Dcomcnfg for a Visual Basic DCOM Client/Server Application > > Basically, in "Security" tab of the component, you disable Remote Launch > and Activation permissions. The users who you see there are allowed to > load the component. The component could start as a different user, and you > can do that by using the "Identity" tab. In this case, Windows starts the > component using the user that you specify, even if that user has higher > privileges than the user who launched it. This can be used in situations > where you want a standard user to do administrative things, for example. > > In your place, I would do it the following way: > > - Use DCOM tool to disable Remote Launch and Activation for all listed > users. You don't need to change anything in Identity tab. > - Create a special user using the application name as the name of the > user. Lets call this VBUser. This user should have no groups assigned to > it. > - Use Windows Explorer to allow this user permissions for Read&Execute to > critical system folders, such as "C:\Windows" and "C:\Program Files". Do > not change the permissions on "Documents and Settings". Windows does that > for you. There are probably other places to add this user to, like in User > Rights Assignment in Local Security Policy, but the simplest solution is > to make this user a member of the Users group. > - Make a Start.exe that calls CreateProcessWithLogonW(). Use > LOGON_WITH_PROFILE flag. However, to save time, you may want to first > create a shortcut to your app, and use the shortcut Advanced button to run > your app as a different user. I think Windows only allows you to use > accounts that don't have blank passwords. If you need to run your app as > SYSTEM, you can't use this method, and instead, create a task in Task > Scheduler(time doesn't matter), specify SYSTEM as the user name and leave > the password blank. Disable the task, then when you want to run it, right > click it and select Run. > > The above so far locks the DLL(and your process) from accessing files > outside the folder that you configured. The DLL can still read the > contents of the OS folders above. > > The DLL can still access other applications running on the same desktop or > terminal session as the logged on user by sending messages. However, in > Vista+, if the logged on user has higher privileges than VBUser, the > messages are blocked. In XP/2003 Server and below, messages are not > blocked even when using different accounts. The only thing that is blocked > between different accounts in Windows 2000+ are hooks, such as by > SetWindowsHookEx. If you want to block messages in 2000/XP/2003, then you > have to use Jobs. In this case, when calling CreateProcessWithLogonW(), > specify CREATE_SUSPENDED flag, and call > CreateJobObject/AssignProcessToJobObject, followed by ResumeThread(). This > works in Vista+ too. > > > |