|
|
You're in the
dotnet security
group:Limiting exe permissions
dotnet security:
I am planning to make this program available as a download from the Internet. Since the program is something you can download from the Internet and since most people are afraid of running application from companies they don't know anything about, I would like to tell my user how to protect them selves from my own application in case they are concern that my program may have a virus or some sort of spy ware (it does not but I can't ask them to blindly trust me). To achive this, I tried running the "Trust and Assembly" utility from the ".Net Wizard" section and set the permission for my application to "None". After doing that, I was expecting not to be able to run the program but I was still able to run it. My question is: What do I need to do to assign a permission to my application so that it is not be able to browse other directories in my computer, access the registry, make screenshots etc. Thanks.
Hello Rene,
that's the default. Just try it - if your program is coming from the internet zone it has very limited permissions. If you want to lower permissions for interet originating programs in general you have to modify the Internet permission set in mscorcfg.msc --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com [quoted text, click to view] > I recently finished a C# program that is based on the .Net 1.1 > framework and I am planning to make this program available as a > download from the Internet. > > Since the program is something you can download from the Internet and > since most people are afraid of running application from companies > they don't know anything about, I would like to tell my user how to > protect them selves from my own application in case they are concern > that my program may have a virus or some sort of spy ware (it does not > but I can't ask them to blindly trust me). > > To achive this, I tried running the "Trust and Assembly" utility from > the ".Net Wizard" section and set the permission for my application to > "None". After doing that, I was expecting not to be able to run the > program but I was still able to run it. > > My question is: What do I need to do to assign a permission to my > application so that it is not be able to browse other directories in > my computer, access the registry, make screenshots etc. > > Thanks. >
[quoted text, click to view]
"Rene" <nospam@nospam.com> wrote in message news:eFB4S7YqFHA.1256@TK2MSFTNGP09.phx.gbl... > Thanks Nicole but...... > > I probably didn't do a good job explaining what I needed but the idea here > is to make my user feel protected against my exe not to protect myself. Assembly-level permission rejections do protect the user. [quoted text, click to view] > If I tell my user that I have added code to my exe to make sure its does > not go out and start deleting their files and that its safe to run it as > administrator without any fear chances are they are not going to believe > me! They don't need to believe you. They can verify the assembly-level permission requests by running permview (http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfpermissionsviewtoolpermviewexe.asp) or any decompiler that exposes the assembly attributes (e.g.: ildasm or reflector). [quoted text, click to view] > The other thing is that all of the assemblies used by my application are > mine so I don't have to worry about locking them down. If you only want to change the permission grant for your main EXE, it makes absolutely no practical difference whether you do this via policy or assembly-level attributes. However, before you decide to limit the permissions of only your main EXE, you might want to consider how other applications may attempt to use the other assemblies you deploy. [quoted text, click to view] > I am not sure if I missed something on your reply, I am kind of new to > this permission thing. So here goes the question again: If *you*were to > download my exe and you didn't trust me Then I wouldn't run your installer application, which is unmanaged code and is completely unconstrained by CAS. [quoted text, click to view] > but the exe is a program that is reeeeeeeeealy cool. What would you do to > be able to use my program (exe) and at the same time feel safe that it > won't go and spy on you? Again, any damage could be done by your installer program, so I wouldn't be willing to run the installer if this was a concern. [quoted text, click to view] > > I appreciate your help, thanks. > > > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > news:eE1nVoWqFHA.3524@tk2msftngp13.phx.gbl... >> Rene, >> >> There's no need to alter CAS policy if you want to restrict your >> assemblies' >> permissions. Instead, you can simply use assembly-level permission >> attributes to reject the permissions that you would prefer the assembly >> not >> be granted. There are two basic approaches to this: >> >> 1. Refuse specific permissions that you don't want (blacklisting), or >> 2. Reject all permissions except the ones you do want (whitelisting). >> >> For #1, simply add RequestRefuse attributes like the following, which >> rejects all file IO permissions: >> >> [assembly: FileIOPermission(SecurityAction.RequestRefuse, Unrestricted = >> true)] >> >> If you would prefer to declaratively request only the permissions your >> assembly actually needs, you should start with a RequestOptional >> attribute >> like the following, which rejects all permissions except >> SecurityPermission\Execution and the identity permissions corresponding >> to >> the assembly's evidence: >> >> [assembly: PermissionSet(SecurityAction.RequestOptional, Unrestricted = >> false)] >> >> Once you've added a RequestOptional attribute, you'll need to add a >> RequestMinimum or RequestOptional for every permission your application >> does >> need. For example, if your application should not even load unless it is >> granted read permission on a dedicated registry key added at >> installation, >> you might add an attribute like the following: >> >> [assembly: RegistryPermission(SecurityAction.RequestMinimum, >> Read = @"HKEY_LOCAL_MACHINE\SOFTWARE\YourCompany\YourApplication")] >> >> HTH, >> Nicole >> >> >> >> >> "Rene" <nospam@nospam.com> wrote in message >> news:eC%23m4oPqFHA.2696@TK2MSFTNGP11.phx.gbl... >>>I recently finished a C# program that is based on the .Net 1.1 framework >>>and I am planning to make this program available as a download from the >>>Internet. >>> >>> Since the program is something you can download from the Internet and >>> since most people are afraid of running application from companies they >>> don't know anything about, I would like to tell my user how to protect >>> them selves from my own application in case they are concern that my >>> program may have a virus or some sort of spy ware (it does not but I >>> can't >>> ask them to blindly trust me). >>> >>> To achive this, I tried running the "Trust and Assembly" utility from >>> the >>> ".Net Wizard" section and set the permission for my application to >>> "None". >>> After doing that, I was expecting not to be able to run the program but >>> I >>> was still able to run it. >>> >>> My question is: What do I need to do to assign a permission to my >>> application so that it is not be able to browse other directories in my >>> computer, access the registry, make screenshots etc. >>> >>> Thanks. >>> >> >> >> > >
Whoops... I just caught that "safe to run it as administrator" bit. If your
application doesn't need "dangerous" CAS permissions, why does it need user admin permissions? [quoted text, click to view] "Rene" <nospam@nospam.com> wrote in message news:eFB4S7YqFHA.1256@TK2MSFTNGP09.phx.gbl... > Thanks Nicole but...... > > I probably didn't do a good job explaining what I needed but the idea here > is to make my user feel protected against my exe not to protect myself. > > If I tell my user that I have added code to my exe to make sure its does > not go out and start deleting their files and that its safe to run it as > administrator without any fear chances are they are not going to believe > me! The other thing is that all of the assemblies used by my application > are mine so I don't have to worry about locking them down. > > I am not sure if I missed something on your reply, I am kind of new to > this permission thing. So here goes the question again: If *you*were to > download my exe and you didn't trust me but the exe is a program that is > reeeeeeeeealy cool. What would you do to be able to use my program (exe) > and at the same time feel safe that it won't go and spy on you? > > I appreciate your help, thanks. > > > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > news:eE1nVoWqFHA.3524@tk2msftngp13.phx.gbl... >> Rene, >> >> There's no need to alter CAS policy if you want to restrict your >> assemblies' >> permissions. Instead, you can simply use assembly-level permission >> attributes to reject the permissions that you would prefer the assembly >> not >> be granted. There are two basic approaches to this: >> >> 1. Refuse specific permissions that you don't want (blacklisting), or >> 2. Reject all permissions except the ones you do want (whitelisting). >> >> For #1, simply add RequestRefuse attributes like the following, which >> rejects all file IO permissions: >> >> [assembly: FileIOPermission(SecurityAction.RequestRefuse, Unrestricted = >> true)] >> >> If you would prefer to declaratively request only the permissions your >> assembly actually needs, you should start with a RequestOptional >> attribute >> like the following, which rejects all permissions except >> SecurityPermission\Execution and the identity permissions corresponding >> to >> the assembly's evidence: >> >> [assembly: PermissionSet(SecurityAction.RequestOptional, Unrestricted = >> false)] >> >> Once you've added a RequestOptional attribute, you'll need to add a >> RequestMinimum or RequestOptional for every permission your application >> does >> need. For example, if your application should not even load unless it is >> granted read permission on a dedicated registry key added at >> installation, >> you might add an attribute like the following: >> >> [assembly: RegistryPermission(SecurityAction.RequestMinimum, >> Read = @"HKEY_LOCAL_MACHINE\SOFTWARE\YourCompany\YourApplication")] >> >> HTH, >> Nicole >> >> >> >> >> "Rene" <nospam@nospam.com> wrote in message >> news:eC%23m4oPqFHA.2696@TK2MSFTNGP11.phx.gbl... >>>I recently finished a C# program that is based on the .Net 1.1 framework >>>and I am planning to make this program available as a download from the >>>Internet. >>> >>> Since the program is something you can download from the Internet and >>> since most people are afraid of running application from companies they >>> don't know anything about, I would like to tell my user how to protect >>> them selves from my own application in case they are concern that my >>> program may have a virus or some sort of spy ware (it does not but I >>> can't >>> ask them to blindly trust me). >>> >>> To achive this, I tried running the "Trust and Assembly" utility from >>> the >>> ".Net Wizard" section and set the permission for my application to >>> "None". >>> After doing that, I was expecting not to be able to run the program but >>> I >>> was still able to run it. >>> >>> My question is: What do I need to do to assign a permission to my >>> application so that it is not be able to browse other directories in my >>> computer, access the registry, make screenshots etc. >>> >>> Thanks. >>> >> >> >> > >
Hello Rene,
yes - you are right! CAS only applies if you start the program "from" the remote location. On the other hand, if you supply a setup program this usually need admin privileges on the client. If your clients are local admins you can't help them anyway :) Well - you could lock down CAS permissions for a local directory but this would mean that users have to start the software from that special directory. --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com [quoted text, click to view] > Well, the download of the setup file is from the Internet but once the > user click on the Setup.exe, the program gets installed on the > computer and I believe it will no longer answer to the Internet > permission right? > > The other option that I am giving my users it to download all the > files via zip file, they can then extract the files to a folder on > their computer and simply double click my exe from them. I believe > that if they do that the Internet permission won't take effect either. > > Am I right? > > "Dominick Baier [DevelopMentor]" > <dbaier@pleasepleasenospamdevelop.com> wrote in message > news:791716632605544772877520@news.microsoft.com... > >> Hello Rene, >> >> that's the default. Just try it - if your program is coming from the >> internet zone it has very limited permissions. If you want to lower >> permissions for interet originating programs in general you have to >> modify the Internet permission set in mscorcfg.msc >> >> --------------------------------------- >> Dominick Baier - DevelopMentor >> http://www.leastprivilege.com >>> I recently finished a C# program that is based on the .Net 1.1 >>> framework and I am planning to make this program available as a >>> download from the Internet. >>> >>> Since the program is something you can download from the Internet >>> and since most people are afraid of running application from >>> companies they don't know anything about, I would like to tell my >>> user how to protect them selves from my own application in case they >>> are concern that my program may have a virus or some sort of spy >>> ware (it does not but I can't ask them to blindly trust me). >>> >>> To achive this, I tried running the "Trust and Assembly" utility >>> from the ".Net Wizard" section and set the permission for my >>> application to "None". After doing that, I was expecting not to be >>> able to run the program but I was still able to run it. >>> >>> My question is: What do I need to do to assign a permission to my >>> application so that it is not be able to browse other directories in >>> my computer, access the registry, make screenshots etc. >>> >>> Thanks. >>>
Well, the download of the setup file is from the Internet but once the user
click on the Setup.exe, the program gets installed on the computer and I believe it will no longer answer to the Internet permission right? The other option that I am giving my users it to download all the files via zip file, they can then extract the files to a folder on their computer and simply double click my exe from them. I believe that if they do that the Internet permission won't take effect either. Am I right? "Dominick Baier [DevelopMentor]" <dbaier@pleasepleasenospamdevelop.com> [quoted text, click to view] wrote in message news:791716632605544772877520@news.microsoft.com... > Hello Rene, > > that's the default. Just try it - if your program is coming from the > internet zone it has very limited permissions. If you want to lower > permissions for interet originating programs in general you have to modify > the Internet permission set in mscorcfg.msc > > --------------------------------------- > Dominick Baier - DevelopMentor > http://www.leastprivilege.com > >> I recently finished a C# program that is based on the .Net 1.1 >> framework and I am planning to make this program available as a >> download from the Internet. >> >> Since the program is something you can download from the Internet and >> since most people are afraid of running application from companies >> they don't know anything about, I would like to tell my user how to >> protect them selves from my own application in case they are concern >> that my program may have a virus or some sort of spy ware (it does not >> but I can't ask them to blindly trust me). >> >> To achive this, I tried running the "Trust and Assembly" utility from >> the ".Net Wizard" section and set the permission for my application to >> "None". After doing that, I was expecting not to be able to run the >> program but I was still able to run it. >> >> My question is: What do I need to do to assign a permission to my >> application so that it is not be able to browse other directories in >> my computer, access the registry, make screenshots etc. >> >> Thanks. >> > > >
Hello Nicole Calinoiu" calinoiu REMOVETHIS AT gmail DOT com,
yes - listen to Nicole. she knows best :) --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com [quoted text, click to view] > Rene, > > There's no need to alter CAS policy if you want to restrict your > assemblies' permissions. Instead, you can simply use assembly-level > permission attributes to reject the permissions that you would prefer > the assembly not be granted. There are two basic approaches to this: > > 1. Refuse specific permissions that you don't want (blacklisting), or > 2. Reject all permissions except the ones you do want (whitelisting). > > For #1, simply add RequestRefuse attributes like the following, which > rejects all file IO permissions: > > [assembly: FileIOPermission(SecurityAction.RequestRefuse, Unrestricted > = true)] > > If you would prefer to declaratively request only the permissions your > assembly actually needs, you should start with a RequestOptional > attribute like the following, which rejects all permissions except > SecurityPermission\Execution and the identity permissions > corresponding to the assembly's evidence: > > [assembly: PermissionSet(SecurityAction.RequestOptional, Unrestricted > = false)] > > Once you've added a RequestOptional attribute, you'll need to add a > RequestMinimum or RequestOptional for every permission your > application does need. For example, if your application should not > even load unless it is granted read permission on a dedicated registry > key added at installation, you might add an attribute like the > following: > > [assembly: RegistryPermission(SecurityAction.RequestMinimum, Read = > @"HKEY_LOCAL_MACHINE\SOFTWARE\YourCompany\YourApplication")] > > HTH, > Nicole > "Rene" <nospam@nospam.com> wrote in message > news:eC%23m4oPqFHA.2696@TK2MSFTNGP11.phx.gbl... >> I recently finished a C# program that is based on the .Net 1.1 >> framework and I am planning to make this program available as a >> download from the Internet. >> >> Since the program is something you can download from the Internet and >> since most people are afraid of running application from companies >> they don't know anything about, I would like to tell my user how to >> protect them selves from my own application in case they are concern >> that my program may have a virus or some sort of spy ware (it does >> not but I can't ask them to blindly trust me). >> >> To achive this, I tried running the "Trust and Assembly" utility from >> the ".Net Wizard" section and set the permission for my application >> to "None". After doing that, I was expecting not to be able to run >> the program but I was still able to run it. >> >> My question is: What do I need to do to assign a permission to my >> application so that it is not be able to browse other directories in >> my computer, access the registry, make screenshots etc. >> >> Thanks. >>
Rene,
There's no need to alter CAS policy if you want to restrict your assemblies' permissions. Instead, you can simply use assembly-level permission attributes to reject the permissions that you would prefer the assembly not be granted. There are two basic approaches to this: 1. Refuse specific permissions that you don't want (blacklisting), or 2. Reject all permissions except the ones you do want (whitelisting). For #1, simply add RequestRefuse attributes like the following, which rejects all file IO permissions: [assembly: FileIOPermission(SecurityAction.RequestRefuse, Unrestricted = true)] If you would prefer to declaratively request only the permissions your assembly actually needs, you should start with a RequestOptional attribute like the following, which rejects all permissions except SecurityPermission\Execution and the identity permissions corresponding to the assembly's evidence: [assembly: PermissionSet(SecurityAction.RequestOptional, Unrestricted = false)] Once you've added a RequestOptional attribute, you'll need to add a RequestMinimum or RequestOptional for every permission your application does need. For example, if your application should not even load unless it is granted read permission on a dedicated registry key added at installation, you might add an attribute like the following: [assembly: RegistryPermission(SecurityAction.RequestMinimum, Read = @"HKEY_LOCAL_MACHINE\SOFTWARE\YourCompany\YourApplication")] HTH, Nicole [quoted text, click to view] "Rene" <nospam@nospam.com> wrote in message news:eC%23m4oPqFHA.2696@TK2MSFTNGP11.phx.gbl... >I recently finished a C# program that is based on the .Net 1.1 framework >and I am planning to make this program available as a download from the >Internet. > > Since the program is something you can download from the Internet and > since most people are afraid of running application from companies they > don't know anything about, I would like to tell my user how to protect > them selves from my own application in case they are concern that my > program may have a virus or some sort of spy ware (it does not but I can't > ask them to blindly trust me). > > To achive this, I tried running the "Trust and Assembly" utility from the > ".Net Wizard" section and set the permission for my application to "None". > After doing that, I was expecting not to be able to run the program but I > was still able to run it. > > My question is: What do I need to do to assign a permission to my > application so that it is not be able to browse other directories in my > computer, access the registry, make screenshots etc. > > Thanks. >
Thanks Nicole but......
I probably didn't do a good job explaining what I needed but the idea here is to make my user feel protected against my exe not to protect myself. If I tell my user that I have added code to my exe to make sure its does not go out and start deleting their files and that its safe to run it as administrator without any fear chances are they are not going to believe me! The other thing is that all of the assemblies used by my application are mine so I don't have to worry about locking them down. I am not sure if I missed something on your reply, I am kind of new to this permission thing. So here goes the question again: If *you*were to download my exe and you didn't trust me but the exe is a program that is reeeeeeeeealy cool. What would you do to be able to use my program (exe) and at the same time feel safe that it won't go and spy on you? I appreciate your help, thanks. [quoted text, click to view] "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message news:eE1nVoWqFHA.3524@tk2msftngp13.phx.gbl... > Rene, > > There's no need to alter CAS policy if you want to restrict your > assemblies' > permissions. Instead, you can simply use assembly-level permission > attributes to reject the permissions that you would prefer the assembly > not > be granted. There are two basic approaches to this: > > 1. Refuse specific permissions that you don't want (blacklisting), or > 2. Reject all permissions except the ones you do want (whitelisting). > > For #1, simply add RequestRefuse attributes like the following, which > rejects all file IO permissions: > > [assembly: FileIOPermission(SecurityAction.RequestRefuse, Unrestricted = > true)] > > If you would prefer to declaratively request only the permissions your > assembly actually needs, you should start with a RequestOptional attribute > like the following, which rejects all permissions except > SecurityPermission\Execution and the identity permissions corresponding to > the assembly's evidence: > > [assembly: PermissionSet(SecurityAction.RequestOptional, Unrestricted = > false)] > > Once you've added a RequestOptional attribute, you'll need to add a > RequestMinimum or RequestOptional for every permission your application > does > need. For example, if your application should not even load unless it is > granted read permission on a dedicated registry key added at installation, > you might add an attribute like the following: > > [assembly: RegistryPermission(SecurityAction.RequestMinimum, > Read = @"HKEY_LOCAL_MACHINE\SOFTWARE\YourCompany\YourApplication")] > > HTH, > Nicole > > > > > "Rene" <nospam@nospam.com> wrote in message > news:eC%23m4oPqFHA.2696@TK2MSFTNGP11.phx.gbl... >>I recently finished a C# program that is based on the .Net 1.1 framework >>and I am planning to make this program available as a download from the >>Internet. >> >> Since the program is something you can download from the Internet and >> since most people are afraid of running application from companies they >> don't know anything about, I would like to tell my user how to protect >> them selves from my own application in case they are concern that my >> program may have a virus or some sort of spy ware (it does not but I >> can't >> ask them to blindly trust me). >> >> To achive this, I tried running the "Trust and Assembly" utility from the >> ".Net Wizard" section and set the permission for my application to >> "None". >> After doing that, I was expecting not to be able to run the program but I >> was still able to run it. >> >> My question is: What do I need to do to assign a permission to my >> application so that it is not be able to browse other directories in my >> computer, access the registry, make screenshots etc. >> >> Thanks. >> > > >
Nah, I just deal well with shock and amazement... ;)
"Dominick Baier [DevelopMentor]" <dbaier@pleasepleasenospamdevelop.com> [quoted text, click to view] wrote in message news:792718632605761010755734@news.microsoft.com... > Hello Nicole Calinoiu" calinoiu REMOVETHIS AT gmail DOT com, > > yes - listen to Nicole. she knows best :) > > --------------------------------------- > Dominick Baier - DevelopMentor > http://www.leastprivilege.com > >> Rene, >> >> There's no need to alter CAS policy if you want to restrict your >> assemblies' permissions. Instead, you can simply use assembly-level >> permission attributes to reject the permissions that you would prefer >> the assembly not be granted. There are two basic approaches to this: >> >> 1. Refuse specific permissions that you don't want (blacklisting), or >> 2. Reject all permissions except the ones you do want (whitelisting). >> >> For #1, simply add RequestRefuse attributes like the following, which >> rejects all file IO permissions: >> >> [assembly: FileIOPermission(SecurityAction.RequestRefuse, Unrestricted >> = true)] >> >> If you would prefer to declaratively request only the permissions your >> assembly actually needs, you should start with a RequestOptional >> attribute like the following, which rejects all permissions except >> SecurityPermission\Execution and the identity permissions >> corresponding to the assembly's evidence: >> >> [assembly: PermissionSet(SecurityAction.RequestOptional, Unrestricted >> = false)] >> >> Once you've added a RequestOptional attribute, you'll need to add a >> RequestMinimum or RequestOptional for every permission your >> application does need. For example, if your application should not >> even load unless it is granted read permission on a dedicated registry >> key added at installation, you might add an attribute like the >> following: >> >> [assembly: RegistryPermission(SecurityAction.RequestMinimum, Read = >> @"HKEY_LOCAL_MACHINE\SOFTWARE\YourCompany\YourApplication")] >> >> HTH, >> Nicole >> "Rene" <nospam@nospam.com> wrote in message >> news:eC%23m4oPqFHA.2696@TK2MSFTNGP11.phx.gbl... >>> I recently finished a C# program that is based on the .Net 1.1 >>> framework and I am planning to make this program available as a >>> download from the Internet. >>> >>> Since the program is something you can download from the Internet and >>> since most people are afraid of running application from companies >>> they don't know anything about, I would like to tell my user how to >>> protect them selves from my own application in case they are concern >>> that my program may have a virus or some sort of spy ware (it does >>> not but I can't ask them to blindly trust me). >>> >>> To achive this, I tried running the "Trust and Assembly" utility from >>> the ".Net Wizard" section and set the permission for my application >>> to "None". After doing that, I was expecting not to be able to run >>> the program but I was still able to run it. >>> >>> My question is: What do I need to do to assign a permission to my >>> application so that it is not be able to browse other directories in >>> my computer, access the registry, make screenshots etc. >>> >>> Thanks. >>> > > >
[quoted text, click to view]
>> I am not sure if I missed something on your reply, I am kind of new to >> this permission thing. So here goes the question again: If *you*were to >> download my exe and you didn't trust me > > Then I wouldn't run your installer application, which is unmanaged code > and is completely unconstrained by CAS. Good observation, I know about this problem! thats why I told Dominick in a previous post the following the following: "The other option that I am giving my users is to download all the files via zip file, they can then extract the files to a folder on their computer and simply double click my exe from there". This will not require running the installer. [quoted text, click to view] > They don't need to believe you. They can verify the assembly-level > permission requests by running permview > (http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfpermissionsviewtoolpermviewexe.asp) > or any decompiler that exposes the assembly attributes (e.g.: ildasm or > reflector). This is good, I was not aware about that however there is a small problem, since my application is targeted for average Joe, most of them won't have a clue of what they are looking at. What I want is a simple way of locking down the application. For example, I can extremely easily run the "Security Adjustment Wizard" and set the "My Computer" zone permission level to the lowest level. Anyone can do this, its very simple. Of course there is a problem with that approach, I believe that the tightest "My Computer" zone permission will still allow the application to browse for files where the user has permissions, the other problem is that this permissions are applied to the whole computer not just a folder where my application is running and that is bad. [quoted text, click to view] > Whoops... I just caught that "safe to run it as administrator" bit. If > your application doesn't need "dangerous" CAS permissions, why does it > need user admin permissions? It does not, but here is the deal. I have become aware that some people are not downloading the application because they are concern that I will spy on their files. Perhaps they have some sensitive information on their computer or perhaps they keep naked pictures of themselves stored on their hard-drives just like I do! (Ok, I was kidding about that one). The problem is that even if you logon as a restricted user, the application can still browse the files you have permissions for which is something they people don't like. <Gasp> I am starting to get the feeling that there will be no easy way to do this. What with the "Code Groups", I was looking at them and I saw that you could select a "Membership Condition" called "Application Directory". Isn't that supposed to do what I need to do? Thanks again.
Yep, can't help but wonder why Microsoft didn't address this security
issues. I bet there are thousands of people that don't use applications from unknown companies because they are afraid of what they are downloading. In my opinion, setting permissions of an executable should be as simple as right clicking the file, go to some tab like the security tab and select an option from a combo box list such as "Full Trust", "Medium Trust", "Don't let this file do anything except run" etc. Finally, there should be some kind of managed installer where you can limit its ability to do anything except what you give it permissions for. Oh well, so much for security. Thanks for your help.
[quoted text, click to view]
"Rene" <nospam@nospam.com> wrote in message news:u$UeBRaqFHA.1328@tk2msftngp13.phx.gbl... >>> I am not sure if I missed something on your reply, I am kind of new to >>> this permission thing. So here goes the question again: If *you*were to >>> download my exe and you didn't trust me >> >> Then I wouldn't run your installer application, which is unmanaged code >> and is completely unconstrained by CAS. > > Good observation, I know about this problem! thats why I told Dominick in > a previous post the following the following: "The other option that I am > giving my users is to download all the files via zip file, they can then > extract the files to a folder on their computer and simply double click my > exe from there". This will not require running the installer. Sorry, I missed that detail. [quoted text, click to view] >> They don't need to believe you. They can verify the assembly-level >> permission requests by running permview >> (http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfpermissionsviewtoolpermviewexe.asp) >> or any decompiler that exposes the assembly attributes (e.g.: ildasm or >> reflector). > > This is good, I was not aware about that however there is a small problem, > since my application is targeted for average Joe, most of them won't have > a clue of what they are looking at. The average Joe won't know or understand anything about CAS either. If you give such users instructions to modify CAS policy, they won't even begin to understand the effects of what they're doing, so it's highly unlikely to increase their trust in your application. Even worse, they might pooch their CAS configurations, in which case they might suspect that you gave them deliberately malicious instructions for the manual configuration. [quoted text, click to view] > What I want is a simple way of locking down the application. For example, > I can extremely easily run the "Security Adjustment Wizard" and set the > "My Computer" zone permission level to the lowest level. Anyone can do > this, its very simple. But will they even begin to understand what it is that they're doing? [quoted text, click to view] > Of course there is a problem with that approach, I believe that the > tightest "My Computer" zone permission will still allow the application to > browse for files where the user has permissions, the other problem is that > this permissions are applied to the whole computer not just a folder where > my application is running and that is bad. In order to apply application-specific restrictions via CAS policy, "level final" code groups must be used. The wizards don't address this level of detail, and it's highly unlikely that your users will even begin to comprehend it. [quoted text, click to view] >> Whoops... I just caught that "safe to run it as administrator" bit. If >> your application doesn't need "dangerous" CAS permissions, why does it >> need user admin permissions? > > It does not, but here is the deal. I have become aware that some people > are not downloading the application because they are concern that I will > spy on their files. Perhaps they have some sensitive information on their > computer or perhaps they keep naked pictures of themselves stored on their > hard-drives just like I do! (Ok, I was kidding about that one). The > problem is that even if you logon as a restricted user, the application > can still browse the files you have permissions for which is something > they people don't like. > > > > <Gasp> I am starting to get the feeling that there will be no easy way to > do this. What with the "Code Groups", I was looking at them and I saw that > you could select a "Membership Condition" called "Application Directory". > Isn't that supposed to do what I need to do? You can certainly create a code group that restricts assembly permissions based on their directory. However, there's no way to do so (or at least not without significant additional automation from your untrusted code <g>) that will be so trivial that "Joe User" will be able to both complete the task will a reasonable probability of success and have the faintest clue as to the consequences of the changes he has applied. To be honest, I suspect that you might need to address technical and non-technical end-users separately. For technically-oriented users, use of permission-rejecting attributes or similar restrictions via CAS policy modifications might be quite sufficient. However, for the general public, you might need a very different approach for building trust, such as reviews from "happy" customers.
[quoted text, click to view]
"Rene" <nospam@nospam.com> wrote in message news:O3h%23BobqFHA.1256@TK2MSFTNGP09.phx.gbl... > Yep, can't help but wonder why Microsoft didn't address this security > issues. Much of the CAS effort has been around directly downloaded code (e.g.: controls hosted on web pages) rather than the locally installed scenario. While I happen to agree with you that the latter deserves addition attention, that's not where past priorities have been. Also, if you take a look at past postings in this newsgroup, you'll probably find a great deal of complaint about the limitations that CAS already imposes. There seem to be far more developers who want their code to be ensured a high privilege grant than are willing to accept the constraints of low CAS privilege, forget about seeking these out on purpose. [quoted text, click to view] > I bet there are thousands of people that don't use applications from > unknown companies because they are afraid of what they are downloading. "Thousands" aren't likely to be a compelling user pool for Microsoft. <g> Luckily, the numbers are probably considerable higher (and growing all the time), which is part of why I'm still hoping that limiting permissions of locally installed code will eventually become a more important goal. [quoted text, click to view] > In my opinion, setting permissions of an executable should be as simple as > right clicking the file, go to some tab like the security tab and select > an option from a combo box list such as "Full Trust", "Medium Trust", > "Don't let this file do anything except run" etc. You might want to take a look at the new ClickOnce functionality in the v. 2.0 .NET Framework, which does address at least some of your concerns. [quoted text, click to view] > Finally, there should be some kind of managed installer where you can > limit its ability to do anything except what you give it permissions for. ClickOnce is a start along those lines, but it does allow a mix with unmanaged components, and naive end users are unlikely to be able to make informed decisions about the consequences of various installation options.
Hi Rene,
I might have misunderstood also but.. At the assembly level, you can use a permission with the "RequestRefuse" attribute, which indicates that you will always refuse the specified permission, for example: using System.IO; using System.Security; using System.Security.Permissions; [assembly: FileIOPermission( SecurityAction.RequestRefuse, Unrestricted=true)] The user can then use the "permview.exe" tool to verify that you indeed refused the specified permission: [quoted text, click to view] >permview windowsApplication1.exe Microsoft (R) .NET Framework Permission Request Viewer. Version 1.1.4322.573 Copyright (C) Microsoft Corporation 1998-2002. All rights reserved. minimal permission set: Not specified optional permission set: Not specified refused permission set: <PermissionSet class="System.Security.PermissionSet" version="1"> <IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=1.0.5000.0, C ulture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true"/> </PermissionSet> Notice the "refused permission set" above.. Hope this helps, Bennie Haelen [quoted text, click to view] Rene wrote:
> Thanks Nicole but...... > > I probably didn't do a good job explaining what I needed but the idea here > is to make my user feel protected against my exe not to protect myself. > > If I tell my user that I have added code to my exe to make sure its does not > go out and start deleting their files and that its safe to run it as > administrator without any fear chances are they are not going to believe me! > The other thing is that all of the assemblies used by my application are > mine so I don't have to worry about locking them down. > > I am not sure if I missed something on your reply, I am kind of new to this > permission thing. So here goes the question again: If *you*were to download > my exe and you didn't trust me but the exe is a program that is > reeeeeeeeealy cool. What would you do to be able to use my program (exe) and > at the same time feel safe that it won't go and spy on you? > > I appreciate your help, thanks. > > > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > news:eE1nVoWqFHA.3524@tk2msftngp13.phx.gbl... > >>Rene, >> >>There's no need to alter CAS policy if you want to restrict your >>assemblies' >>permissions. Instead, you can simply use assembly-level permission >>attributes to reject the permissions that you would prefer the assembly >>not >>be granted. There are two basic approaches to this: >> >>1. Refuse specific permissions that you don't want (blacklisting), or >>2. Reject all permissions except the ones you do want (whitelisting). >> >>For #1, simply add RequestRefuse attributes like the following, which >>rejects all file IO permissions: >> >>[assembly: FileIOPermission(SecurityAction.RequestRefuse, Unrestricted = >>true)] >> >>If you would prefer to declaratively request only the permissions your >>assembly actually needs, you should start with a RequestOptional attribute >>like the following, which rejects all permissions except >>SecurityPermission\Execution and the identity permissions corresponding to >>the assembly's evidence: >> >>[assembly: PermissionSet(SecurityAction.RequestOptional, Unrestricted = >>false)] >> >>Once you've added a RequestOptional attribute, you'll need to add a >>RequestMinimum or RequestOptional for every permission your application >>does >>need. For example, if your application should not even load unless it is >>granted read permission on a dedicated registry key added at installation, >>you might add an attribute like the following: >> >>[assembly: RegistryPermission(SecurityAction.RequestMinimum, >>Read = @"HKEY_LOCAL_MACHINE\SOFTWARE\YourCompany\YourApplication")] >> >>HTH, >>Nicole >> >> >> >> >>"Rene" <nospam@nospam.com> wrote in message >>news:eC%23m4oPqFHA.2696@TK2MSFTNGP11.phx.gbl... >> >>>I recently finished a C# program that is based on the .Net 1.1 framework >>>and I am planning to make this program available as a download from the >>>Internet. >>> >>>Since the program is something you can download from the Internet and >>>since most people are afraid of running application from companies they >>>don't know anything about, I would like to tell my user how to protect >>>them selves from my own application in case they are concern that my >>>program may have a virus or some sort of spy ware (it does not but I >>>can't >>>ask them to blindly trust me). >>> >>>To achive this, I tried running the "Trust and Assembly" utility from the >>>".Net Wizard" section and set the permission for my application to >>>"None". >>>After doing that, I was expecting not to be able to run the program but I >>>was still able to run it. >>> >>>My question is: What do I need to do to assign a permission to my >>>application so that it is not be able to browse other directories in my >>>computer, access the registry, make screenshots etc. >>> >>>Thanks. >>> >> >> >> >
Thanks
[quoted text, click to view] "Bennie Haelen" <Bennie.Haelen@jda.com> wrote in message
news:%23t595voqFHA.3136@TK2MSFTNGP11.phx.gbl... > Hi Rene, > > I might have misunderstood also but.. > > At the assembly level, you can use a permission with the "RequestRefuse" > attribute, which indicates that you will always refuse the specified > permission, for example: > > using System.IO; > using System.Security; > using System.Security.Permissions; > [assembly: FileIOPermission( > SecurityAction.RequestRefuse, Unrestricted=true)] > > The user can then use the "permview.exe" tool to verify that you indeed > refused the specified permission: > > >permview windowsApplication1.exe > > Microsoft (R) .NET Framework Permission Request Viewer. Version > 1.1.4322.573 > Copyright (C) Microsoft Corporation 1998-2002. All rights reserved. > > minimal permission set: > Not specified > > optional permission set: > Not specified > > refused permission set: > <PermissionSet class="System.Security.PermissionSet" > version="1"> > <IPermission class="System.Security.Permissions.FileIOPermission, > mscorlib, Version=1.0.5000.0, C > ulture=neutral, PublicKeyToken=b77a5c561934e089" > version="1" > Unrestricted="true"/> > </PermissionSet> > > > Notice the "refused permission set" above.. > > Hope this helps, > > Bennie Haelen > Rene wrote: >> Thanks Nicole but...... >> >> I probably didn't do a good job explaining what I needed but the idea >> here is to make my user feel protected against my exe not to protect >> myself. >> >> If I tell my user that I have added code to my exe to make sure its does >> not go out and start deleting their files and that its safe to run it as >> administrator without any fear chances are they are not going to believe >> me! The other thing is that all of the assemblies used by my application >> are mine so I don't have to worry about locking them down. >> >> I am not sure if I missed something on your reply, I am kind of new to >> this permission thing. So here goes the question again: If *you*were to >> download my exe and you didn't trust me but the exe is a program that is >> reeeeeeeeealy cool. What would you do to be able to use my program (exe) >> and at the same time feel safe that it won't go and spy on you? >> >> I appreciate your help, thanks. >> >> >> >> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message >> news:eE1nVoWqFHA.3524@tk2msftngp13.phx.gbl... >> >>>Rene, >>> >>>There's no need to alter CAS policy if you want to restrict your >>>assemblies' >>>permissions. Instead, you can simply use assembly-level permission >>>attributes to reject the permissions that you would prefer the assembly >>>not >>>be granted. There are two basic approaches to this: >>> >>>1. Refuse specific permissions that you don't want (blacklisting), or >>>2. Reject all permissions except the ones you do want (whitelisting). >>> >>>For #1, simply add RequestRefuse attributes like the following, which >>>rejects all file IO permissions: >>> >>>[assembly: FileIOPermission(SecurityAction.RequestRefuse, Unrestricted = >>>true)] >>> >>>If you would prefer to declaratively request only the permissions your >>>assembly actually needs, you should start with a RequestOptional >>>attribute >>>like the following, which rejects all permissions except >>>SecurityPermission\Execution and the identity permissions corresponding >>>to >>>the assembly's evidence: >>> >>>[assembly: PermissionSet(SecurityAction.RequestOptional, Unrestricted = >>>false)] >>> >>>Once you've added a RequestOptional attribute, you'll need to add a >>>RequestMinimum or RequestOptional for every permission your application >>>does >>>need. For example, if your application should not even load unless it is >>>granted read permission on a dedicated registry key added at >>>installation, >>>you might add an attribute like the following: >>> >>>[assembly: RegistryPermission(SecurityAction.RequestMinimum, >>>Read = @"HKEY_LOCAL_MACHINE\SOFTWARE\YourCompany\YourApplication")] >>> >>>HTH, >>>Nicole >>> >>> >>> >>> >>>"Rene" <nospam@nospam.com> wrote in message >>>news:eC%23m4oPqFHA.2696@TK2MSFTNGP11.phx.gbl... >>> >>>>I recently finished a C# program that is based on the .Net 1.1 framework >>>>and I am planning to make this program available as a download from the >>>>Internet. >>>> >>>>Since the program is something you can download from the Internet and >>>>since most people are afraid of running application from companies they >>>>don't know anything about, I would like to tell my user how to protect >>>>them selves from my own application in case they are concern that my >>>>program may have a virus or some sort of spy ware (it does not but I >>>>can't >>>>ask them to blindly trust me). >>>> >>>>To achive this, I tried running the "Trust and Assembly" utility from >>>>the >>>>".Net Wizard" section and set the permission for my application to >>>>"None". >>>>After doing that, I was expecting not to be able to run the program but >>>>I >>>>was still able to run it. >>>> >>>>My question is: What do I need to do to assign a permission to my >>>>application so that it is not be able to browse other directories in my >>>>computer, access the registry, make screenshots etc. >>>> >>>>Thanks. >>>> >>> >>> >>> >>
Thanks
[quoted text, click to view] "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message news:e8k35PjqFHA.248@TK2MSFTNGP14.phx.gbl... > "Rene" <nospam@nospam.com> wrote in message > news:O3h%23BobqFHA.1256@TK2MSFTNGP09.phx.gbl... >> Yep, can't help but wonder why Microsoft didn't address this security >> issues. > > Much of the CAS effort has been around directly downloaded code (e.g.: > controls hosted on web pages) rather than the locally installed scenario. > While I happen to agree with you that the latter deserves addition > attention, that's not where past priorities have been. Also, if you take > a look at past postings in this newsgroup, you'll probably find a great > deal of complaint about the limitations that CAS already imposes. There > seem to be far more developers who want their code to be ensured a high > privilege grant than are willing to accept the constraints of low CAS > privilege, forget about seeking these out on purpose. > > >> I bet there are thousands of people that don't use applications from >> unknown companies because they are afraid of what they are downloading. > > "Thousands" aren't likely to be a compelling user pool for Microsoft. <g> > Luckily, the numbers are probably considerable higher (and growing all the > time), which is part of why I'm still hoping that limiting permissions of > locally installed code will eventually become a more important goal. > > >> In my opinion, setting permissions of an executable should be as simple >> as right clicking the file, go to some tab like the security tab and >> select an option from a combo box list such as "Full Trust", "Medium >> Trust", "Don't let this file do anything except run" etc. > > You might want to take a look at the new ClickOnce functionality in the v. > 2.0 .NET Framework, which does address at least some of your concerns. > > >> Finally, there should be some kind of managed installer where you can >> limit its ability to do anything except what you give it permissions for. > > ClickOnce is a start along those lines, but it does allow a mix with > unmanaged components, and naive end users are unlikely to be able to make > informed decisions about the consequences of various installation options. >
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 |