Re: Getting logged in user from a service?

"Larry Smith" <no_spam@xxxxxxxxxxx> wrote in message news:OC8YH$6pHHA.2156@xxxxxxxxxxxxxxxxxxxxxxx
Not at all, WMI is client/server based using DCOM, you call a service and the service executes the service call, when WMI needs to "enable" a privilege (note that I said 'enable'), it' s up to the caller to ask the service to enable the required (whatever this one may be)privilege, the user doesn't need to know the "privilege" required, WMI know which one as it's stored in it's metabase.
In the exceptional case (there are only a few) that a call requires a privilege that is not held by the WMI account (say "Network Service"), then it's up to the caller to run as a more privileged user (or get a stronger logon token) and ask WMI to impersonate when executing the service call.

Part of my argument has been in response to these (sometimes) confusiing comments about security. All WMI would be doing here is enabling privileges that are already present in the caller's token (not its own). That's what Ben Voight was referring to in his earlier response. It's a minor convenience but one that's expected over the native OS since WMI sits on top of it (providing higher-level services). If you don't have the required privilege(s) in the first place however then WMI can't help you. Nor should impersonation be required here since it's not needed. Your earlier comments such as "... most of these things are taken care of by the framework and it's underlying services" and " ... WMI makes it possible to call OS services without YOU having the need to run with these elevated privileges" are therefore misleading. Security is still an issue that needs to be considered but you've been implying otherwise. In any case, I can't counter arguments about ease-of-use in general. Higher-level services are inherently easier to use by their very nature so it's compelling to champion their use. They're not always the right tool for the job however. The entire crux of my argument centers around that and their place in a service in particular. I find your earlier arguments about monolithic services as self-defeating in fact since there's no special threshold involved here. Nor is memory consumption (necessarily) an accurate indicator of just how big these apps really are (since memory is affected by other things such as the amount of client data currently being cached). A small footprint is therefore a relative term. Imagine how much larger and slower those services would be if they actually relied on .NET instead of C++ and the native OS (which they most likely do at the core). Do you think MSFT or most organizations would even consider .NET for most services? Not likely.



All WMI's security levels are highly customizable, the namespaces are all protected by DACL's you can adjust, you can prevent certain user to access, read, write, execute etc...it's namespaces, if a user is allowed to execute a method, WMI will simply enable or add the privilege (to it's own token)when needed on a per call basis.

Some classes and methods need an impersonation token from the base client, if the token holds a needed privilege to execute or access a namespace class, WMI enables this privilege, when the token misses the privilege, the call fails.
That way it's possible to perform some administrative tasks without you, the client, to run as an administrator, you are simply delegating the task to another more privileged process, which on it's turn is rather restricted.
Look back at what Nicholas proposed, get the Handle of another process, if you don't run in the same logon session, you won't be able to access to process object to obtain the Handle (that is, Win32 OpenProcess will return access denied) unless you are running as administrator and even then, you won't probably be able to get all handles, there is nothing you can do without a process handle, game over. This is not an issue when using WMI (or System.Management, this is .NET right!).

Just try this as non administrator,

Process [] procs= Process.GetProcesses();
foreach(Process pro in procs)
{
try {
IntPtr handle = pro.Handle;
}
catch( Exception ex){Console.WriteLine(ex);}
}
and watch all:
System.ComponentModel.Win32Exception: Access is denied
at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throw
IfExited)
thrown on you ...

This is exactly why so many programs run in the "administrators" account these days, worse some have "SeDebugPrivilege" enabled, talking about a surface attack.

Willy.






.

Relevant Pages

  • Re: Security woes
    ... a Moniker like you were using prior will execute as the user account ... The reason is that WMI ... > enables all sorts of usages of the computer including rebooting, ... To access wmi from a remote ...
    (microsoft.public.win32.programmer.wmi)
  • Re: Getting logged in user from a service?
    ... against the OS services (that is, by directly calling WIN32 Api's) you have to consider a lot of things at "development" time, things like - is the API available on the *target* machine? ... Most of these things are taken care of by the framework and it's underlying services, whatever these are, and in this particular case the underlying service is native WMI in top of Win32. ... I don't see how using .NET Framework exempts you from worrying about security constraints, privileges, etc. ... It might automatically enable a held privilege in your token, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Getting logged in user from a service?
    ... the service executes the service call, when WMI needs to "enable" a ... privilege, it' s up to the caller to ask the ... user doesn't need to know the "privilege" required, WMI know which one as ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Set previlege with Windows Management
    ... setting EnablePrivilege to "true" should 'enable' all privileges ... required to execute a specific WMI class methods. ... Note that the principal must have been granted the required privilege (see ... PS.Please post System.Management (WMI) related questions to ...
    (microsoft.public.dotnet.general)
  • Re: Set previlege with Windows Management
    ... > required to execute a specific WMI class methods. ... > PS.Please post System.Management related questions to ... >> include the RemoteShutdown privilege when connecting to WMI. ... >> control the shutdown behavior. ...
    (microsoft.public.dotnet.general)