| Groups | Blog | Home |
dotnet security : Need advise...
Dear all,
I have a windows application with a Windows login dialog which is used to handle different specific users different that Windows login users. When I start my application I get a security exception when I am loged in as a Restricted Windows user. The generated exception is normal becasue my application login windows, read some registry data before beeing displayed and by default restricted users do not have access rights to registry. My question is : What is the best and proper way to be able to read and right data to my application Installation key in the registry even with a restricted user ? Do I have to defined declarative acces to the function which reads or write inside my code ? or Do I have to usse the CAS configuration ? I have try to use the second solution, the defined a new Code group, then attach a new Permision set for that group with "Application Directory" rule and then define the Read/write permision for registry. But that does not seems to work. Thnaks for your advise regards
"serge calderara" <sergecalderara@discussions.microsoft.com> wrote in
message news:9B052532-CEE9-48FB-A06A-AA82A86404E5@microsoft.com... <snip> [quoted text, click to view] > What is the best and proper way to be able to read You should have no problems reading from your app's key under HKLM as a non-admin. If this isn't working, could you please post the full key path as well as the full exception details (including call stack listing), as returned from its ToString method? [quoted text, click to view] > and right data to my > application Installation key in the registry even with a restricted user ? Only write to your application's key under HKLM when running under an admin account (e.g.: at installation). When running as a non-admin, write a separate key under HKCU instead. [quoted text, click to view] > Do I have to defined declarative acces to the function which reads or > write > inside my code ? > > or > > Do I have to usse the CAS configuration ? I have try to use the second > solution, the defined a new Code group, then attach a new Permision set > for > that group with "Application Directory" rule and then define the > Read/write > permision for registry. But that does not seems to work. CAS will not help you bypass user permissions on the registry keys. If your application is locally installed, you are presumably running with unrestricted CAS permissions anyway, so you should not need to mess with CAS at all in this scenario.
hi nicole, nice to see you here again. For reading no problem as you said, but I am writing too. So I will follow your advice to use current user key instead but then when I have build my deployement package, my installation write my application entry under Local machine, do I have to change my setup package to create my applciation key in Current user instead or leave it like this and simply use the current user key whenever writing is needed ? regards serge [quoted text, click to view] "Nicole Calinoiu" wrote:
> "serge calderara" <sergecalderara@discussions.microsoft.com> wrote in > message news:9B052532-CEE9-48FB-A06A-AA82A86404E5@microsoft.com... > <snip> > > What is the best and proper way to be able to read > > You should have no problems reading from your app's key under HKLM as a > non-admin. If this isn't working, could you please post the full key path > as well as the full exception details (including call stack listing), as > returned from its ToString method? > > > > and right data to my > > application Installation key in the registry even with a restricted user ? > > Only write to your application's key under HKLM when running under an admin > account (e.g.: at installation). When running as a non-admin, write a > separate key under HKCU instead. > > > > Do I have to defined declarative acces to the function which reads or > > write > > inside my code ? > > > > or > > > > Do I have to usse the CAS configuration ? I have try to use the second > > solution, the defined a new Code group, then attach a new Permision set > > for > > that group with "Application Directory" rule and then define the > > Read/write > > permision for registry. But that does not seems to work. > > CAS will not help you bypass user permissions on the registry keys. If your > application is locally installed, you are presumably running with > unrestricted CAS permissions anyway, so you should not need to mess with CAS > at all in this scenario. > >
unfortunately the registry APIs also return SecurityExceptions (IIRC) - which
is a little annoying. --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com [quoted text, click to view] > Hi Nicole, > >> You should have no problems reading from your app's key under HKLM as >> a non-admin. If this isn't working, could you please post the full >> key path as well as the full exception details (including call stack >> listing), as returned from its ToString method? >> > here are two keys that you can't read as non-admin ;-) > > HKLM\SAM\SAM and > HKLM\SECURITY > And I guess the exception will be "Access denied" :D > > -Valery. > http://www.harper.no/valery > Nicole Calinoiu wrote: > >> "serge calderara" <sergecalderara@discussions.microsoft.com> wrote in >> message news:9B052532-CEE9-48FB-A06A-AA82A86404E5@microsoft.com... >> <snip> >> >>> What is the best and proper way to be able to read >>> >> You should have no problems reading from your app's key under HKLM as >> a non-admin. If this isn't working, could you please post the full >> key path as well as the full exception details (including call stack >> listing), as returned from its ToString method? >> >>> and right data to my >>> application Installation key in the registry even with a restricted >>> user ? >> Only write to your application's key under HKLM when running under an >> admin account (e.g.: at installation). When running as a non-admin, >> write a separate key under HKCU instead. >> >>> Do I have to defined declarative acces to the function which reads >>> or >>> write >>> inside my code ? >>> or >>> >>> Do I have to usse the CAS configuration ? I have try to use the >>> second >>> solution, the defined a new Code group, then attach a new Permision >>> set >>> for >>> that group with "Application Directory" rule and then define the >>> Read/write >>> permision for registry. But that does not seems to work. >> CAS will not help you bypass user permissions on the registry keys. >> If your application is locally installed, you are presumably running >> with unrestricted CAS permissions anyway, so you should not need to >> mess with CAS at all in this scenario. >>
Sure, but would you use those for your "application Installation key"? <gdr>
[quoted text, click to view] "Valery Pryamikov" <valery@harper.no> wrote in message news:1150876541.668145.146260@y41g2000cwy.googlegroups.com... > Hi Nicole, > >> You should have no problems reading from your app's key under HKLM as a >> non-admin. If this isn't working, could you please post the full key >> path >> as well as the full exception details (including call stack listing), as >> returned from its ToString method? > > here are two keys that you can't read as non-admin ;-) > > HKLM\SAM\SAM and > HKLM\SECURITY > > And I guess the exception will be "Access denied" :D > > -Valery. > http://www.harper.no/valery > > Nicole Calinoiu wrote: >> "serge calderara" <sergecalderara@discussions.microsoft.com> wrote in >> message news:9B052532-CEE9-48FB-A06A-AA82A86404E5@microsoft.com... >> <snip> >> > What is the best and proper way to be able to read >> >> You should have no problems reading from your app's key under HKLM as a >> non-admin. If this isn't working, could you please post the full key >> path >> as well as the full exception details (including call stack listing), as >> returned from its ToString method? >> >> >> > and right data to my >> > application Installation key in the registry even with a restricted >> > user ? >> >> Only write to your application's key under HKLM when running under an >> admin >> account (e.g.: at installation). When running as a non-admin, write a >> separate key under HKCU instead. >> >> >> > Do I have to defined declarative acces to the function which reads or >> > write >> > inside my code ? >> > >> > or >> > >> > Do I have to usse the CAS configuration ? I have try to use the second >> > solution, the defined a new Code group, then attach a new Permision set >> > for >> > that group with "Application Directory" rule and then define the >> > Read/write >> > permision for registry. But that does not seems to work. >> >> CAS will not help you bypass user permissions on the registry keys. If >> your >> application is locally installed, you are presumably running with >> unrestricted CAS permissions anyway, so you should not need to mess with >> CAS >> at all in this scenario. >
"serge calderara" <sergecalderara@discussions.microsoft.com> wrote in
message news:94D2F46C-90B8-4CE0-93C6-BB280009ED77@microsoft.com... [quoted text, click to view] > For reading no problem as you said, but I am writing too. So I will follow > your advice to use current user key instead but then when I have build my > deployement package, my installation write my application entry under > Local > machine, do I have to change my setup package to create my applciation key > in > Current user instead or leave it like this and simply use the current user > key whenever writing is needed ? Adding the key under HKCU at installation doesn't really make much sense since the installing user won't necessarily ever run your application. For other users, the key will need to be created at runtime anyway, so you might as well just go ahead and only create it at runtime (assuming, of course, that it doesn't already exist).
Hi Nicole,
[quoted text, click to view] > You should have no problems reading from your app's key under HKLM as a > non-admin. If this isn't working, could you please post the full key path > as well as the full exception details (including call stack listing), as > returned from its ToString method? here are two keys that you can't read as non-admin ;-) HKLM\SAM\SAM and HKLM\SECURITY And I guess the exception will be "Access denied" :D -Valery. http://www.harper.no/valery [quoted text, click to view] Nicole Calinoiu wrote:
> "serge calderara" <sergecalderara@discussions.microsoft.com> wrote in > message news:9B052532-CEE9-48FB-A06A-AA82A86404E5@microsoft.com... > <snip> > > What is the best and proper way to be able to read > > You should have no problems reading from your app's key under HKLM as a > non-admin. If this isn't working, could you please post the full key path > as well as the full exception details (including call stack listing), as > returned from its ToString method? > > > > and right data to my > > application Installation key in the registry even with a restricted user ? > > Only write to your application's key under HKLM when running under an admin > account (e.g.: at installation). When running as a non-admin, write a > separate key under HKCU instead. > > > > Do I have to defined declarative acces to the function which reads or > > write > > inside my code ? > > > > or > > > > Do I have to usse the CAS configuration ? I have try to use the second > > solution, the defined a new Code group, then attach a new Permision set > > for > > that group with "Application Directory" rule and then define the > > Read/write > > permision for registry. But that does not seems to work. > > CAS will not help you bypass user permissions on the registry keys. If your > application is locally installed, you are presumably running with > unrestricted CAS permissions anyway, so you should not need to mess with CAS > at all in this scenario.
Thaks nicole for your advise...
regards serge [quoted text, click to view] "Nicole Calinoiu" wrote:
> "serge calderara" <sergecalderara@discussions.microsoft.com> wrote in > message news:94D2F46C-90B8-4CE0-93C6-BB280009ED77@microsoft.com... > > For reading no problem as you said, but I am writing too. So I will follow > > your advice to use current user key instead but then when I have build my > > deployement package, my installation write my application entry under > > Local > > machine, do I have to change my setup package to create my applciation key > > in > > Current user instead or leave it like this and simply use the current user > > key whenever writing is needed ? > > Adding the key under HKCU at installation doesn't really make much sense > since the installing user won't necessarily ever run your application. For > other users, the key will need to be created at runtime anyway, so you might > as well just go ahead and only create it at runtime (assuming, of course, > that it doesn't already exist). > >
One comments cone to my mind is that adding the registry key from
installation instead of runtime offer the advantage to get a complete cleaning of application entry during un installation. serge [quoted text, click to view] "Nicole Calinoiu" wrote:
> "serge calderara" <sergecalderara@discussions.microsoft.com> wrote in > message news:94D2F46C-90B8-4CE0-93C6-BB280009ED77@microsoft.com... > > For reading no problem as you said, but I am writing too. So I will follow > > your advice to use current user key instead but then when I have build my > > deployement package, my installation write my application entry under > > Local > > machine, do I have to change my setup package to create my applciation key > > in > > Current user instead or leave it like this and simply use the current user > > key whenever writing is needed ? > > Adding the key under HKCU at installation doesn't really make much sense > since the installing user won't necessarily ever run your application. For > other users, the key will need to be created at runtime anyway, so you might > as well just go ahead and only create it at runtime (assuming, of course, > that it doesn't already exist). > >
Not if other users also run the application. If you're concerned about
potential version incompatibilities, write to versions-specific subkeys. Otherwise, if you really want to clean out all the users' registry entries at uninstall time, you can write a custom uninstall task to run through HKEY_USERS and delete you app's keys. "serge calderara" <sergecalderara@discussions.microsoft.com> wrote in message news:17E5318E-CC23-4403-8646-C30F80648C34@microsoft.com... [quoted text, click to view] > One comments cone to my mind is that adding the registry key from > installation instead of runtime offer the advantage to get a complete > cleaning of application entry during un installation. > > serge > > "Nicole Calinoiu" wrote: > >> "serge calderara" <sergecalderara@discussions.microsoft.com> wrote in >> message news:94D2F46C-90B8-4CE0-93C6-BB280009ED77@microsoft.com... >> > For reading no problem as you said, but I am writing too. So I will >> > follow >> > your advice to use current user key instead but then when I have build >> > my >> > deployement package, my installation write my application entry under >> > Local >> > machine, do I have to change my setup package to create my applciation >> > key >> > in >> > Current user instead or leave it like this and simply use the current >> > user >> > key whenever writing is needed ? >> >> Adding the key under HKCU at installation doesn't really make much sense >> since the installing user won't necessarily ever run your application. >> For >> other users, the key will need to be created at runtime anyway, so you >> might >> as well just go ahead and only create it at runtime (assuming, of course, >> that it doesn't already exist). >> >> >>
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |