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

[Guest]

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

 

[Jimmy Brush]

Hello,

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/windowsvi...l=/library/en-us/dnlong/html/AccProtVista.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/archive/2006/04/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/windowsvi...l=/library/en-us/dnlong/html/AccProtVista.asp

 

[Guest]

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]

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.

 

[Guest]

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]

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/vistacompatt...sAdmin-or-CreateElevatedComObject-sample.aspx

 

[Guest]

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

 

[Guest]

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.

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.

 

[Guest]

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

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.

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 Brush]

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/archive/2004/05/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

 

[Guest]

Thanks JB,

As developers we have a early view of Vista and its security. It remains to
be seen how the consumers will react.

I think Microsoft is betting that users will complain and then comply /
accept. But deep in their hearts they will not understand / know enough
about what the security permissions are doing and resent all the new dialogs.

thanks for the advice about proper service usage AND the link. My service
was looking a bit like the "bad" example and so I'll try the more OOP
design...


--
Thanks so much,

george

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

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/archive/2004/05/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/

 

[Jimmy Brush]

As developers we have a early view of Vista and its security. It remains
to
be seen how the consumers will react.
Agreed.

I think Microsoft is betting that users will complain and then comply /
accept. But deep in their hearts they will not understand / know enough
about what the security permissions are doing and resent all the new
dialogs.

Do you really think so? I don't. But you're right, it is too early to tell.
And I'm sure some users will agree with you.

But remember this: The users that don't like UAC can turn it off. When UAC
is turned off, your program will NOT PROMPT users. (For example, you could
implement the COM solution, and when UAC is turned off, instantiating the
com component as admin will work silently and not throw a permission
prompt).

Although UAC seems like its just a hassle, it really does offer users
powerful control over their computer. Most programs don't need admin
permissions. The ones that really do, can just ask for permission when
necessary. Only a very few programs will need admin permission on startup.

This translates into very few admin permission boxes for the majority of
users (by the time most apps get ported/patched ... granted this could take
a while) - which means teaching users how to handle them is possible. Not to
mention the innumerable security benefits of applications finally being
rearchitected to work in a least-privileged scenario.

In your statement here, you are forgetting the users that want their systems
to be secure. And the users that like UAC and want it turned on (and YES
they are out there, they are here in this newsgroup [not just me ] and I
have seen them other places as well).

Following the correct programming model by using UAC will allow your program
to work in BOTH of these situations: UAC ON will prompt users, UAC OFF will
NOT prompt users. This is a win-win scenario.

Because, as you said, you DON'T know how this thing is going to take off ...
why hedge your bets?

OK, I'm done trying to convince you. I tried my best, and I have enjoyed
this discussion

Good luck with your application.

 

[Kurt Harriger]

These registry keys are restricted for a reason and only administrators
should change them. Windows currently doesn't offer SUID so in order for an
administrator to pre-approve the action you must unfortunatly create a
window service or com+ application. I would think a COM+ app running as a
service user would be easier as you can delegate the authentication and
authorization tasks to the COM+ system. But if you write a windows service
you must becareful about who else might be able to use this service, you
don't want to just open a tcp port to the world that accepts a simple text
message "change setting key <value>" even if it is restricted to just the
Location setting, the administrator should have full knowedge of not only
what system settings can be changed but also by whom and is entrusting you
to block all unauthorized users, guets/remote users. This is why I wish
windows had SUID because it is far to complicated for administrators to
pre-approve administrative tasks such as yours and if implemented
incorrectly could create potential exploits for hackers.

- Kurt

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/archive/2004/05/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/