How to perform High security tasks from a low level security app??

Hello,

In other threads, I've seen recommendations to in order to circumvent the
vista permissions dialogs that they build their .net application with a
manifest in a particular way.

How to do the equivalent from C++?

Is there a "manifest" technique?

A special COM solution?

Special Registry settings (set during install -while enjoying admin rights)


I've created a COM exe with a method that implements CreateProcess. And
successfully call this from an IE7 app while running in Protected Mode.


How to do this in other places than IE??

--
Thanks so much,

george

_________________________
George S. Lockwood
Lead Client Developer
peoplePC, an EarthLink company

Hello,

<snip>
> I've created a COM exe with a method that implements
> CreateProcess. And successfully call this from an IE7
> app while running in Protected Mode.

In this case, the app that you run from CreateProcess should also be running
in IE7 protected mode, unless you are using the new interface in IE7 that
prompts the user for consent in order to "break out" of protected mode.

Vista is designed so that apps running in different privilege levels are
seperated, and whenever a lower-privileged application wants to start or
interact with a higher-privileged one, user consent is required. I.E.
protected-mode IE requires user consent to launch a non-protected-mode app
or access things that are restricted from protected-mode.

In the same vein, when a user wants to start a program that requires admin
permission, user consent is required unless the program that is wanting to
start the elevated program is an elevated program itself.

So, following this abstraction, the correct way to implement your
application, assuming it only needs admin permission to do certain, specific
tasks and can be run without admin permission most of the time (kind of like
windows explorer), is to seperate out the chunks that need admin permission
into seperate COM components or exe's, and only call/launch them when
necessary.

When launching these secondary processes, you will need to programatically
specify that they need admin permission (or in the case of an EXE, you can
embed a special manifest that tells Windows it needs admin) and then it will
prompt the user for permission and elevate the COM/exe so that it can do its
admin tasks.

Or, if your entire application is say a systems utility that needs admin
permission just to run, you should embed a manifest into the app specifying
that it always needs admin access, and the system will automatically prompt
the user for permission and give the app admin access every time it is run,
without you needing to do anything programatically (more on that later).

Here's a good document that explains this sort of thing:

http://msdn.microsoft.com/windowsvis...cProtVista.asp


Now, the other situation you may encounter, is where you need your program
to be able to perform a task that in and of itself should not need admin
permssion, but the task must have admin permission to be implemented. For
example, the act of virus scanning should not require admin permission, but
implementing the virus scan itself does.

To do this sort of thing, you should implement a windows service that
performs these high-level tasks. Your application, running as a standard
user via UAC, should then call this service using some IPC mechanism to
perform these high-level tasks.

NOTE, however, that when implementing a service in this manner, you should
NOT be allowing your program to specifically do admin-related tasks; I.E.
you shouldn't make a mechanism using this service to allow your application
to write to restricted registry keys.

Your application should NOT be able to "break out of its security box" when
using your service - and you should take great care to ensure that this is
not possible. The service ITSELF should be able to do admin-related things
in order to implement whatever tasks that it needs to do, but this power
should not 'leak' back out to the application.

For example, the service may need to access security-restricted things to
perform its duties (for example, the virus scanner needs to access all files
regardless of security permissions). But in doing so the service must ensure
that it does not leak such power to the lower-privileged application using
its services (i.e. the virus scanner UI running as a standard user should
NOT be able to use the virus scanning interface to access files it does not
normally have access to - it should only be able to do abstract virus
scanning related functions)

I know this is a very fine distinction, and I hope I have explained it well


OK more info on manifests:

A manifest is simply a Win32 resource that is linked into a program module.
It is not limited to .NET exe's. The manifest tells Vista how much
permission your program needs.

This does not 'bypass' Vista's permission dialogs in any way - it tells
Windows Vista how much access your program needs to the computer.

If your program always requires administrator permission, for example, Vista
will ask the user for permission to start your program every time it is
started, because the only way for programs to run with admin permissions in
Vista is thru user consent.

If your program requires 'as much permission as the user has', then your
program will NOT prompt the user for permission if they are a standard user
and will have only standard user permission, but WILL prompt if the user is
an admin and will have admin permission (again, because apps that use admin
permission must get user consent).

Or, if your app never requires admin permission, then it will never prompt
at all, and never have admin permission.

More info on manifests:

http://blogs.msdn.com/shawnfa/archiv...06/568563.aspx
(note that step 3 gives instruction on how to embed the .res file into a
..net exe - instead of this, use the C++ method of doing this)

http://msdn.microsoft.com/windowsvis...cProtVista.asp

--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/

Are you saying -in effect- that there is no way to avoid the "permission"
dialogs if I want to say write to a restricted area of the registry?

One way of the other, the dialog will appear and require user input?

--
Thanks so much,

george

_________________________
George S. Lockwood
Lead Client Developer
peoplePC, an EarthLink company



"Jimmy Brush" wrote:

> Hello,
>
> <snip>
> > I've created a COM exe with a method that implements
> > CreateProcess. And successfully call this from an IE7
> > app while running in Protected Mode.
>
> In this case, the app that you run from CreateProcess should also be running
> in IE7 protected mode, unless you are using the new interface in IE7 that
> prompts the user for consent in order to "break out" of protected mode.
>
> Vista is designed so that apps running in different privilege levels are
> seperated, and whenever a lower-privileged application wants to start or
> interact with a higher-privileged one, user consent is required. I.E.
> protected-mode IE requires user consent to launch a non-protected-mode app
> or access things that are restricted from protected-mode.
>
> In the same vein, when a user wants to start a program that requires admin
> permission, user consent is required unless the program that is wanting to
> start the elevated program is an elevated program itself.
>
> So, following this abstraction, the correct way to implement your
> application, assuming it only needs admin permission to do certain, specific
> tasks and can be run without admin permission most of the time (kind of like
> windows explorer), is to seperate out the chunks that need admin permission
> into seperate COM components or exe's, and only call/launch them when
> necessary.
>
> When launching these secondary processes, you will need to programatically
> specify that they need admin permission (or in the case of an EXE, you can
> embed a special manifest that tells Windows it needs admin) and then it will
> prompt the user for permission and elevate the COM/exe so that it can do its
> admin tasks.
>
> Or, if your entire application is say a systems utility that needs admin
> permission just to run, you should embed a manifest into the app specifying
> that it always needs admin access, and the system will automatically prompt
> the user for permission and give the app admin access every time it is run,
> without you needing to do anything programatically (more on that later).
>
> Here's a good document that explains this sort of thing:
>
> http://msdn.microsoft.com/windowsvis...cProtVista.asp
>
>
> Now, the other situation you may encounter, is where you need your program
> to be able to perform a task that in and of itself should not need admin
> permssion, but the task must have admin permission to be implemented. For
> example, the act of virus scanning should not require admin permission, but
> implementing the virus scan itself does.
>
> To do this sort of thing, you should implement a windows service that
> performs these high-level tasks. Your application, running as a standard
> user via UAC, should then call this service using some IPC mechanism to
> perform these high-level tasks.
>
> NOTE, however, that when implementing a service in this manner, you should
> NOT be allowing your program to specifically do admin-related tasks; I.E.
> you shouldn't make a mechanism using this service to allow your application
> to write to restricted registry keys.
>
> Your application should NOT be able to "break out of its security box" when
> using your service - and you should take great care to ensure that this is
> not possible. The service ITSELF should be able to do admin-related things
> in order to implement whatever tasks that it needs to do, but this power
> should not 'leak' back out to the application.
>
> For example, the service may need to access security-restricted things to
> perform its duties (for example, the virus scanner needs to access all files
> regardless of security permissions). But in doing so the service must ensure
> that it does not leak such power to the lower-privileged application using
> its services (i.e. the virus scanner UI running as a standard user should
> NOT be able to use the virus scanning interface to access files it does not
> normally have access to - it should only be able to do abstract virus
> scanning related functions)
>
> I know this is a very fine distinction, and I hope I have explained it well
>
>
> OK more info on manifests:
>
> A manifest is simply a Win32 resource that is linked into a program module.
> It is not limited to .NET exe's. The manifest tells Vista how much
> permission your program needs.
>
> This does not 'bypass' Vista's permission dialogs in any way - it tells
> Windows Vista how much access your program needs to the computer.
>
> If your program always requires administrator permission, for example, Vista
> will ask the user for permission to start your program every time it is
> started, because the only way for programs to run with admin permissions in
> Vista is thru user consent.
>
> If your program requires 'as much permission as the user has', then your
> program will NOT prompt the user for permission if they are a standard user
> and will have only standard user permission, but WILL prompt if the user is
> an admin and will have admin permission (again, because apps that use admin
> permission must get user consent).
>
> Or, if your app never requires admin permission, then it will never prompt
> at all, and never have admin permission.
>
> More info on manifests:
>
> http://blogs.msdn.com/shawnfa/archiv...06/568563.aspx
> (note that step 3 gives instruction on how to embed the .res file into a
> .net exe - instead of this, use the C++ method of doing this)
>
> http://msdn.microsoft.com/windowsvis...cProtVista.asp
>
> --
> - JB
>
> Windows Vista Support Faq
> http://www.jimmah.com/vista/
>

> Are you saying -in effect- that there is no way to avoid the "permission"
> dialogs if I want to say write to a restricted area of the registry?
>
> One way of the other, the dialog will appear and require user input?

Yes, that is correct .

Allowing such a 'feature' would break Vista's security model.

The only exception to this rule is either a windows service or an
appropriately configured scheduled task - these things run with "admin"
privileges without prompting the user. However, these things are prohibited
from showing a user interface to the user - they cannot interact with the
desktop.

--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/

Thanks, Jimmy!

This is close to my needs. Because of a business model, I may be forced to
continue to use some of the now "restricted-by-Vista" resources. Developing
a Windows Service that can be called upon remotely (via my own well managed
and secure method) to write to the reg and CreateProcess might be the
solution.

So I gather...I would:

1. Build the service.

2. Install, register, and start it during s/w installation (i.e. when admin
rights are in effect).

3. Call on the service when I need to perform my special tasks.


As these are utility tasks, I am fine with the non-UI nature.


BUT Jimmy, suppose I register a "utility" COM component -when admin rights
are in effect. My "low" level app creates instance on the COM and then calls
the methods (to carry out "restricted" tasks)...

....would this be an alternative?


--
Thanks so much,

george

_________________________
George S. Lockwood
Lead Client Developer
peoplePC, an EarthLink company



"Jimmy Brush" wrote:

> > Are you saying -in effect- that there is no way to avoid the "permission"
> > dialogs if I want to say write to a restricted area of the registry?
> >
> > One way of the other, the dialog will appear and require user input?
>
> Yes, that is correct .
>
> Allowing such a 'feature' would break Vista's security model.
>
> The only exception to this rule is either a windows service or an
> appropriately configured scheduled task - these things run with "admin"
> privileges without prompting the user. However, these things are prohibited
> from showing a user interface to the user - they cannot interact with the
> desktop.
>
> --
> - JB
>
> Windows Vista Support Faq
> http://www.jimmah.com/vista/
>

> BUT Jimmy, suppose I register a "utility" COM component -when admin rights
> are in effect. My "low" level app creates instance on the COM and then
> calls
> the methods (to carry out "restricted" tasks)...
>
> ...would this be an alternative?

Again, this a completely acceptable way of doing things, but creating the
admin COM component would ask the user for permission.

More info on the COM side of things can be found here:

https://blogs.msdn.com/vistacompatte...ct-sample.aspx


--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/

Hello JB,

Thanks for your help so far! I've just reread this msg and I'll apologize
up front for its unpleasant tone!! It's exasperation!

I have 2 questions for ...

Suppose an app need to write to the following registry in HKLM:

"Software\\Microsoft\\Windows\\CurrentVersion\\Telephony\\Locations\\Location"

and several others. Is it the Vista security model that the developer must
"collect" all these into a COM object, make a call on its method...and the
user is prompted with the annoying permissions dialog nuisance every time the
component is called!

If so, many apps--well behaved and secure in every sense-- will appear to
the user as malware! This is very unfriendly and frankly wrong!


Question 2. Windows Service & RPC Solution.
If I was to create a windows service to handle such cases as you suggest.
Would the following be true?

1. I can write the service in C++ (.net is not required).

2. The service must registered at its time of installation (during an
administor's session).

3. The service would start -WITHOUT permission dialogs- at system startup.

What other special considerations would need to be handled?

Is there a link devoted to this subject??


--
Thanks so much,

george

_________________________
George S. Lockwood
Lead Client Developer
peoplePC, an EarthLink company



"GSLockwood (IUnknown)" wrote:

> Thanks, Jimmy!
>
> This is close to my needs. Because of a business model, I may be forced to
> continue to use some of the now "restricted-by-Vista" resources. Developing
> a Windows Service that can be called upon remotely (via my own well managed
> and secure method) to write to the reg and CreateProcess might be the
> solution.
>
> So I gather...I would:
>
> 1. Build the service.
>
> 2. Install, register, and start it during s/w installation (i.e. when admin
> rights are in effect).
>
> 3. Call on the service when I need to perform my special tasks.
>
>
> As these are utility tasks, I am fine with the non-UI nature.
>
>
> BUT Jimmy, suppose I register a "utility" COM component -when admin rights
> are in effect. My "low" level app creates instance on the COM and then calls
> the methods (to carry out "restricted" tasks)...
>
> ...would this be an alternative?
>
>
> --
> Thanks so much,
>
> george
>
> _________________________
> George S. Lockwood
> Lead Client Developer
> peoplePC, an EarthLink company
>
>
>
> "Jimmy Brush" wrote:
>
> > > Are you saying -in effect- that there is no way to avoid the "permission"
> > > dialogs if I want to say write to a restricted area of the registry?
> > >
> > > One way of the other, the dialog will appear and require user input?
> >
> > Yes, that is correct .
> >
> > Allowing such a 'feature' would break Vista's security model.
> >
> > The only exception to this rule is either a windows service or an
> > appropriately configured scheduled task - these things run with "admin"
> > privileges without prompting the user. However, these things are prohibited
> > from showing a user interface to the user - they cannot interact with the
> > desktop.
> >
> > --
> > - JB
> >
> > Windows Vista Support Faq
> > http://www.jimmah.com/vista/
> >

<snip>
> Thanks for your help so far! I've just reread this msg and I'll apologize
> up front for its unpleasant tone!! It's exasperation!

You're welcome No need to appologise, your posts are very well written.

<snip>
> Suppose an app need to write to [...] HKLM [...]
> Is it the Vista security model that the developer must
> "collect" all these into a COM object, make a call on its method...and the
> user is prompted with the annoying permissions dialog nuisance every time
> the
> component is called!

I believe UAC is prompted when the COM object is instantiated, not on method
calls.

But that is correct - you are making a SYSTEM-LEVEL change to the operating
system. You are doing something that affects both the entire computer and
other users that use the system. This sort of change REQUIRES admin
permission. If the user is an admin, they must approve your application to
do this action. If the user is NOT an admin, they must get permission from
an admin to take this action.

I really hope I am making this make sense .

The reason you are having so much trouble is because you are trying to do
something you shouldn't do (bypass user consent).

Windows has changed (or more precisely, Windows
is now enforcing something what it has tried to enforce all along). Admins
now control whether an application has the authority to affect the system
state or affect other users.

> If so, many apps--well behaved and secure in every sense-- will appear to
> the user as malware! This is very unfriendly and frankly wrong!

UAC prompting has nothing to do with whether your program is "good" or "bad"
-
and a permission prompt DOES NOT indicate malware! This has to do with
putting the user in control. Your program, when running inside of a user
account, has implicit permission to access files/settings that are DIRECTLY
associated with that user account. If you want to go mucking about with the
system, your program MUST get permission from an administrator. If the user
is an admin, then they have to give their permission, because they need to
know which programs are mucking with their system.

And, I should point out here, that ALL PROGRAMS are under this same
restriciton - not just YOURS.

If someone is wanting to implement a service
just to bypass UAC and not for a very good reason (and I'm not saying
you are - I just want to say this here so everyone can see it) --
I would say to them PLEASE DON'T.
Doing so would be doing users a grave disservice because allowing
non-privileged processes to carry out privileged operations
inevitably allows ANY non-privileged processes to carry out those
operations (even if the method of invokation is obfuscated or some
security scheme is attempted, it is impossible to prevent - if this weren't
so, then UAC would not be necessary in the first place).

This is a great video on channel 9 that goes more in-depth into the concepts
of UAC that you may wish to view:

http://channel9.msdn.com/Showpost.aspx?postid=255622


> Question 2. Windows Service & RPC Solution.
> If I was to create a windows service to handle such cases as you suggest.
> Would the following be true?
>
> 1. I can write the service in C++ (.net is not required).

Yes

> 2. The service must registered at its time of installation (during an
> administor's session).

Well, it doesn't HAVE to be registered at this time, but it would make the
most sense. It must be registered by a program that is running with
administrator privileges.

> 3. The service would start -WITHOUT permission dialogs- at system startup.

Correct.

> What other special considerations would need to be handled?
> Is there a link devoted to this subject??

I will try and find some more information for you.


--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/

Jimmy,

Thanks for your comments and advice.


I believe the intent of MS is worthy. My concern lies with the IMPRESSION
the users will feel when they get the permission dialogs. "What is going
on?", "What is this application doing (that is so 'dangerous' to merit this
window)?", and such.

My apps write to hardward registry keys that windows uses (as well) so it
looks like I'm stuck with a lousy user experience or the windows service
solution.


I am wondering if you know a link to a (VS2005) window service project ? I
have written on but it doesn't stop properly. It would be great to have a
bare bones skeleton service project (not just for this UAC issue, but for
completely unrealted, future projects).


--
Thanks so much,

george

_________________________
George S. Lockwood
Lead Client Developer
peoplePC, an EarthLink company



"Jimmy Brush" wrote:

> <snip>
> > Thanks for your help so far! I've just reread this msg and I'll apologize
> > up front for its unpleasant tone!! It's exasperation!
>
> You're welcome No need to appologise, your posts are very well written.
>
> <snip>
> > Suppose an app need to write to [...] HKLM [...]
> > Is it the Vista security model that the developer must
> > "collect" all these into a COM object, make a call on its method...and the
> > user is prompted with the annoying permissions dialog nuisance every time
> > the
> > component is called!
>
> I believe UAC is prompted when the COM object is instantiated, not on method
> calls.
>
> But that is correct - you are making a SYSTEM-LEVEL change to the operating
> system. You are doing something that affects both the entire computer and
> other users that use the system. This sort of change REQUIRES admin
> permission. If the user is an admin, they must approve your application to
> do this action. If the user is NOT an admin, they must get permission from
> an admin to take this action.
>
> I really hope I am making this make sense .
>
> The reason you are having so much trouble is because you are trying to do
> something you shouldn't do (bypass user consent).
>
> Windows has changed (or more precisely, Windows
> is now enforcing something what it has tried to enforce all along). Admins
> now control whether an application has the authority to affect the system
> state or affect other users.
>
> > If so, many apps--well behaved and secure in every sense-- will appear to
> > the user as malware! This is very unfriendly and frankly wrong!
>
> UAC prompting has nothing to do with whether your program is "good" or "bad"
> -
> and a permission prompt DOES NOT indicate malware! This has to do with
> putting the user in control. Your program, when running inside of a user
> account, has implicit permission to access files/settings that are DIRECTLY
> associated with that user account. If you want to go mucking about with the
> system, your program MUST get permission from an administrator. If the user
> is an admin, then they have to give their permission, because they need to
> know which programs are mucking with their system.
>
> And, I should point out here, that ALL PROGRAMS are under this same
> restriciton - not just YOURS.
>
> If someone is wanting to implement a service
> just to bypass UAC and not for a very good reason (and I'm not saying
> you are - I just want to say this here so everyone can see it) --
> I would say to them PLEASE DON'T.
> Doing so would be doing users a grave disservice because allowing
> non-privileged processes to carry out privileged operations
> inevitably allows ANY non-privileged processes to carry out those
> operations (even if the method of invokation is obfuscated or some
> security scheme is attempted, it is impossible to prevent - if this weren't
> so, then UAC would not be necessary in the first place).
>
> This is a great video on channel 9 that goes more in-depth into the concepts
> of UAC that you may wish to view:
>
> http://channel9.msdn.com/Showpost.aspx?postid=255622
>
>
> > Question 2. Windows Service & RPC Solution.
> > If I was to create a windows service to handle such cases as you suggest.
> > Would the following be true?
> >
> > 1. I can write the service in C++ (.net is not required).
>
> Yes
>
> > 2. The service must registered at its time of installation (during an
> > administor's session).
>
> Well, it doesn't HAVE to be registered at this time, but it would make the
> most sense. It must be registered by a program that is running with
> administrator privileges.
>
> > 3. The service would start -WITHOUT permission dialogs- at system startup.
>
> Correct.
>
> > What other special considerations would need to be handled?
> > Is there a link devoted to this subject??
>
> I will try and find some more information for you.
>
>
> --
> - JB
>
> Windows Vista Support Faq
> http://www.jimmah.com/vista/
>

> I believe the intent of MS is worthy. My concern lies with the IMPRESSION
> the users will feel when they get the permission dialogs. "What is going
> on?", "What is this application doing (that is so 'dangerous' to merit
> this
> window)?", and such.

Well, it is a big deal to give a program administrative access to the
computer. It's your company's job to make sure the user understands what you
are doing with this power. For example, Windows Explorer uses this security
model - you can see it in action when trying to delete/copy files to
restricted areas. It will first pop up an informational window telling you
exactly what's going on and that it needs your permission - and then when
the user clicks continue, a real UAC prompt is issued.

This is the way all applications that require admin-power will work in the
future. Most will use this Windows-explorer style elevate-when-needed model,
but some will always ask the user for permission when the program starts and
run entirely as admin.

My point here being, your application will look normal by issuing these
prompts in the Windows Vista world. It would look abnormal if it didn't
issue the prompts.

> My apps write to hardward registry keys that windows uses (as well) so it
> looks like I'm stuck with a lousy user experience or the windows service
> solution.

I don't know the details of your application, so I can't recommend anything
here. But, if your application only needs to write into this restricted area
every so often (like when the user changes a setting), using the 'lousy'
user experience is the best way to go. However, if this is something that
needs to be modified constantly, your program is not an admin tool, and it
runs every time the computer starts, then I can understand wanting to put
that functionality into a service.

> I am wondering if you know a link to a (VS2005) window service project ?
> I
> have written on but it doesn't stop properly. It would be great to have a
> bare bones skeleton service project (not just for this UAC issue, but for
> completely unrealted, future projects).

This article looked pretty interesting, but I haven't tested the code:

http://weblogs.asp.net/kennykerr/arc...18/134342.aspx

Also, if you do decide to implement the service, here's some tips:

1) Put all the logic that affects admin-related stuff in the service.

For example of what NOT to do:

// Any user-mode program can use your service to access HKLM!
HRESULT WriteStringValueToHKLM(char *subkey, char *name, char *value)
{
RegOpenKey(HKEY_LOCAL_MACHINE, subkey, ...);
...
}

Better:

// This function doesn't directly expose access to the registry - it only
allows turning
// on/off pre-defined values.
HRESULT ModifySetting(int settingId, bool on)
{
RegOpenKey(HKEY_LOCAL_MACHINE, SettingIdToSubkey(settingId), ...);
...
}

(And, in this example, if you are storing the list of settings that can be
turned on/off in a config file, MAKE SURE the config file is
security-restricted so that only administrators [or the user your service
runs under] have read/write access to it, and everyone else no access

2) Windows Vista allows you to lock down your service so it only has access
to the bare minimum resources that it needs in order to function. Use this
feature! If your service only needs access to 3 registry keys, don't give it
access to ANYTHING else; this way, if there's a bug in your service (or it
leaks privileges) someone exploiting it won't be able to uber-harm the
user's computer.

You can even specify to Windows that your service should only have access to
certain files/registry keys/etc that expliclty grant that service access
(which would be set during setup), and no more.

Unfortunately, I am unable to find developer documentation for this feature;
they should be somewhere in that windows sdk though

Good luck

--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/