| Groups | Blog | Home |
dotnet security : can you put a strong name assembly in a role?
The simple version of my question is this: how can you (or can you) set
security so that a privileged assembly can only be called by a specific strong named assembly? I got hopeful when I found out about the strong name condition for a code group in cas, but now it seems like all you can do with cas is define what an assembly can call and never what can call the assembly. I hope I am just missing something obvious. My goal here is to use the privileged application to return credential information to the calling program. I can achieve rights elevation using COM+ and putting a low privileged user in a role for the COM+ app, but this bothers me since if anybody figures out how to call the privileged assembly they can get the credentials. The assembly runs as an account that has privileges in a SQL Server table. If I could simply add a strong named assembly to a role for the com+ app instead of a user or a group, my trouble would be over. Please help with any thoughts on this matter. It will be much appreciated. Daren
[quoted text, click to view]
"ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote in message news:10136359-B677-4B44-8941-27EC06730221@microsoft.com... > The simple version of my question is this: how can you (or can you) set > security so that a privileged assembly can only be called by a specific > strong named assembly? Sort of, but the protection isn't worth much. You can add (link)demands for StrongNameIdentityPermission (or any other identity permission) to the target assembly. However, it's quite trivial for highly privileged code (FullTrust trant or even partial permission set that includes certain key CAS permissions) to bypass such a demand. In addition, in the v. 2.0 framework, all fully trusted assemblies will automatically pass such demands, so this approach will no longer protect against even unintentional misuse of types or members protected by such demands. All in all, not exactly worth the bother... [quoted text, click to view] > I got hopeful when I found out about the strong name > condition for a code group in cas, but now it seems like all you can do > with > cas is define what an assembly can call and never what can call the > assembly. > I hope I am just missing something obvious. Well, if you keep digging, you may find identity permission demands advocated for this but, as mentioned above, they're not particular effective against deliberate misuse even in the v. 1.x framework. [quoted text, click to view] > My goal here is to use the privileged application to return credential > information to the calling program. I can achieve rights elevation using > COM+ and putting a low privileged user in a role for the COM+ app, but > this > bothers me since if anybody figures out how to call the privileged > assembly > they can get the credentials. The assembly runs as an account that has > privileges in a SQL Server table. > > If I could simply add a strong named assembly to a role for the com+ app > instead of a user or a group, my trouble would be over. Not really. You would then need to worry about protecting the calling assembly. Even if you use low visibility (private, internal) types and members to handle the credentials processing in this assembly, these would be exposed to any highly privileged code via reflection. [quoted text, click to view] > Please help with any thoughts on this matter. It will be much > appreciated. Since you already seem to be comfortable with the idea of using a COM+ application to run in an alternate identity context, have you considered performing the subset of operations that involve actual use of the credentials under a similar COM+ app? If this doesn't seem reasonable, might you be willing to explain how the retrieved credentials actually get used? (It's a lot easier to suggest alternate approaches when one knows the goal as well as the problem. <g>) [quoted text, click to view] > > Daren >
Thanks for your thoughts. I hadn't fully thought out the CAS model since it
is new to me, but it would have sounded like the answer to demand the permission, except for your discouragement of this approach. That seems disappointing to me, but I suppose there must be reasons, or not. [quoted text, click to view] "Nicole Calinoiu" wrote: > Since you already seem to be comfortable with the idea of using a COM+ > application to run in an alternate identity context, have you considered > performing the subset of operations that involve actual use of the > credentials under a similar COM+ app? I did consider this, and it seemed perfect until I could not figure out how to lauch a browser window in the proper desktop. If I host the com+ app as a service it can be done if I run it as system, but it runs as a specific user and I can't figure out the UI context switching I guess using window stations or something. Currently over my head. My goal here is to pass the credentials to a control device that hosts a minimal web server, and receives basic authentication over SSL. The server can't be configured for authentication type so I don't know what else to do. The problem exists because the credentials can't be known by the users for business reasons. I think I promised more than I can deliver here. I still have to figure out a safe way to send the credentials to the page on the server, and I played with ideas like modifying the security rule that prevents passing user:password@- type URLs. That can't be good. We might have settled for a way to automate entry of passwords in the protected storage part of the registry and just let the users see the username, but I can't figure that out either and it seems like a bad idea. Anyway, I'm rambling now, and this probably just sounds misguided in the first place, but if you have any suggestions, then thanks in advance. [quoted text, click to view] "Nicole Calinoiu" wrote:
> "ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote in message > news:10136359-B677-4B44-8941-27EC06730221@microsoft.com... > > The simple version of my question is this: how can you (or can you) set > > security so that a privileged assembly can only be called by a specific > > strong named assembly? > > Sort of, but the protection isn't worth much. You can add (link)demands for > StrongNameIdentityPermission (or any other identity permission) to the > target assembly. However, it's quite trivial for highly privileged code > (FullTrust trant or even partial permission set that includes certain key > CAS permissions) to bypass such a demand. In addition, in the v. 2.0 > framework, all fully trusted assemblies will automatically pass such > demands, so this approach will no longer protect against even unintentional > misuse of types or members protected by such demands. All in all, not > exactly worth the bother... > > > > I got hopeful when I found out about the strong name > > condition for a code group in cas, but now it seems like all you can do > > with > > cas is define what an assembly can call and never what can call the > > assembly. > > I hope I am just missing something obvious. > > Well, if you keep digging, you may find identity permission demands > advocated for this but, as mentioned above, they're not particular effective > against deliberate misuse even in the v. 1.x framework. > > > > My goal here is to use the privileged application to return credential > > information to the calling program. I can achieve rights elevation using > > COM+ and putting a low privileged user in a role for the COM+ app, but > > this > > bothers me since if anybody figures out how to call the privileged > > assembly > > they can get the credentials. The assembly runs as an account that has > > privileges in a SQL Server table. > > > > If I could simply add a strong named assembly to a role for the com+ app > > instead of a user or a group, my trouble would be over. > > Not really. You would then need to worry about protecting the calling > assembly. Even if you use low visibility (private, internal) types and > members to handle the credentials processing in this assembly, these would > be exposed to any highly privileged code via reflection. > > > > Please help with any thoughts on this matter. It will be much > > appreciated. > > Since you already seem to be comfortable with the idea of using a COM+ > application to run in an alternate identity context, have you considered > performing the subset of operations that involve actual use of the > credentials under a similar COM+ app? If this doesn't seem reasonable, > might you be willing to explain how the retrieved credentials actually get > used? (It's a lot easier to suggest alternate approaches when one knows the > goal as well as the problem. <g>) > > > > > > Daren > > > >
[quoted text, click to view]
"ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote in message news:8B941039-05C0-497B-8F35-B3B83782B7E0@microsoft.com... <snip> > I did consider this, and it seemed perfect until I could not figure out > how > to lauch a browser window in the proper desktop. If I host the com+ app > as a > service it can be done if I run it as system, but it runs as a specific > user > and I can't figure out the UI context switching I guess using window > stations > or something. Currently over my head. My goal here is to pass the > credentials to a control device that hosts a minimal web server, and > receives > basic authentication over SSL. Do you actually need a browser window for this? Is this not something that could be done, for example, by connecting to the device web server via code? Once authenticated, how is the user intended to interact with the device? [quoted text, click to view] > The server can't be configured for > authentication type so I don't know what else to do. To be honest, I doubt that the authentication type would make much difference with respect to your focal problem. [quoted text, click to view] > The problem exists > because the credentials can't be known by the users for business reasons. Hmm... If the credentials are meant to protect the device, and your application grants the user the same level of access to the device, why do you care if the users actually know the credentials or not? (I can see a few potential reasons, but each has a very different first line solution than what you've described so far.) [quoted text, click to view] > I think I promised more than I can deliver here. I still have to figure > out > a safe way to send the credentials to the page on the server, and I played > with ideas like modifying the security rule that prevents passing > user:password@- type URLs. That can't be good. No, it can't. <g> It also won't really address your central problem, as far as I can tell. [quoted text, click to view] > > We might have settled for a way to automate entry of passwords in the > protected storage part of the registry and just let the users see the > username, but I can't figure that out either and it seems like a bad idea. > > Anyway, I'm rambling now, and this probably just sounds misguided in the > first place, but if you have any suggestions, then thanks in advance. > > > "Nicole Calinoiu" wrote: > >> "ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote in >> message >> news:10136359-B677-4B44-8941-27EC06730221@microsoft.com... >> > The simple version of my question is this: how can you (or can you) >> > set >> > security so that a privileged assembly can only be called by a specific >> > strong named assembly? >> >> Sort of, but the protection isn't worth much. You can add (link)demands >> for >> StrongNameIdentityPermission (or any other identity permission) to the >> target assembly. However, it's quite trivial for highly privileged code >> (FullTrust trant or even partial permission set that includes certain key >> CAS permissions) to bypass such a demand. In addition, in the v. 2.0 >> framework, all fully trusted assemblies will automatically pass such >> demands, so this approach will no longer protect against even >> unintentional >> misuse of types or members protected by such demands. All in all, not >> exactly worth the bother... >> >> >> > I got hopeful when I found out about the strong name >> > condition for a code group in cas, but now it seems like all you can do >> > with >> > cas is define what an assembly can call and never what can call the >> > assembly. >> > I hope I am just missing something obvious. >> >> Well, if you keep digging, you may find identity permission demands >> advocated for this but, as mentioned above, they're not particular >> effective >> against deliberate misuse even in the v. 1.x framework. >> >> >> > My goal here is to use the privileged application to return credential >> > information to the calling program. I can achieve rights elevation >> > using >> > COM+ and putting a low privileged user in a role for the COM+ app, but >> > this >> > bothers me since if anybody figures out how to call the privileged >> > assembly >> > they can get the credentials. The assembly runs as an account that has >> > privileges in a SQL Server table. >> > >> > If I could simply add a strong named assembly to a role for the com+ >> > app >> > instead of a user or a group, my trouble would be over. >> >> Not really. You would then need to worry about protecting the calling >> assembly. Even if you use low visibility (private, internal) types and >> members to handle the credentials processing in this assembly, these >> would >> be exposed to any highly privileged code via reflection. >> >> >> > Please help with any thoughts on this matter. It will be much >> > appreciated. >> >> Since you already seem to be comfortable with the idea of using a COM+ >> application to run in an alternate identity context, have you considered >> performing the subset of operations that involve actual use of the >> credentials under a similar COM+ app? If this doesn't seem reasonable, >> might you be willing to explain how the retrieved credentials actually >> get >> used? (It's a lot easier to suggest alternate approaches when one knows >> the >> goal as well as the problem. <g>) >> >> >> > >> > Daren >> > >> >> >>
The device we are connecting to is a control system with a touch panel
interface. The web server capability of the device allows you to view a virtual exact copy of the touch panel interface and control it as if you were at the device. Basically all we need is to be able to limit the use of this to a small number of machines in our office. If the credentials are known, the device could be accessed from anywhere. The web server on the device can't be configured to limit access only to certain ip addresses, so we thought we should be able to just create a way to automatically pass the credentials using a custom interface only installed on the machines that need the access. Perhaps it would be better to allow knowledge of credentials and limit access to the device to certain hostnames instead, but I don't know how that can be done. Do you? I'm starting to feel that this may be impossible but I always hate to have to accept impossibility so I am pressing on perhaps in futility. Might we implement some sort of intermediary web page on our IIS server? This sounds intriguing. [quoted text, click to view] "Nicole Calinoiu" wrote:
> "ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote in message > news:8B941039-05C0-497B-8F35-B3B83782B7E0@microsoft.com... > <snip> > > I did consider this, and it seemed perfect until I could not figure out > > how > > to lauch a browser window in the proper desktop. If I host the com+ app > > as a > > service it can be done if I run it as system, but it runs as a specific > > user > > and I can't figure out the UI context switching I guess using window > > stations > > or something. Currently over my head. My goal here is to pass the > > credentials to a control device that hosts a minimal web server, and > > receives > > basic authentication over SSL. > > Do you actually need a browser window for this? Is this not something that > could be done, for example, by connecting to the device web server via code? > Once authenticated, how is the user intended to interact with the device? > > > > > The server can't be configured for > > authentication type so I don't know what else to do. > > To be honest, I doubt that the authentication type would make much > difference with respect to your focal problem. > > > > The problem exists > > because the credentials can't be known by the users for business reasons. > > Hmm... If the credentials are meant to protect the device, and your > application grants the user the same level of access to the device, why do > you care if the users actually know the credentials or not? (I can see a > few potential reasons, but each has a very different first line solution > than what you've described so far.) > > > > > I think I promised more than I can deliver here. I still have to figure > > out > > a safe way to send the credentials to the page on the server, and I played > > with ideas like modifying the security rule that prevents passing > > user:password@- type URLs. That can't be good. > > No, it can't. <g> It also won't really address your central problem, as > far as I can tell. > > > > > > We might have settled for a way to automate entry of passwords in the > > protected storage part of the registry and just let the users see the > > username, but I can't figure that out either and it seems like a bad idea. > > > > Anyway, I'm rambling now, and this probably just sounds misguided in the > > first place, but if you have any suggestions, then thanks in advance. > > > > > > "Nicole Calinoiu" wrote: > > > >> "ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote in > >> message > >> news:10136359-B677-4B44-8941-27EC06730221@microsoft.com... > >> > The simple version of my question is this: how can you (or can you) > >> > set > >> > security so that a privileged assembly can only be called by a specific > >> > strong named assembly? > >> > >> Sort of, but the protection isn't worth much. You can add (link)demands > >> for > >> StrongNameIdentityPermission (or any other identity permission) to the > >> target assembly. However, it's quite trivial for highly privileged code > >> (FullTrust trant or even partial permission set that includes certain key > >> CAS permissions) to bypass such a demand. In addition, in the v. 2.0 > >> framework, all fully trusted assemblies will automatically pass such > >> demands, so this approach will no longer protect against even > >> unintentional > >> misuse of types or members protected by such demands. All in all, not > >> exactly worth the bother... > >> > >> > >> > I got hopeful when I found out about the strong name > >> > condition for a code group in cas, but now it seems like all you can do > >> > with > >> > cas is define what an assembly can call and never what can call the > >> > assembly. > >> > I hope I am just missing something obvious. > >> > >> Well, if you keep digging, you may find identity permission demands > >> advocated for this but, as mentioned above, they're not particular > >> effective > >> against deliberate misuse even in the v. 1.x framework. > >> > >> > >> > My goal here is to use the privileged application to return credential > >> > information to the calling program. I can achieve rights elevation > >> > using > >> > COM+ and putting a low privileged user in a role for the COM+ app, but > >> > this > >> > bothers me since if anybody figures out how to call the privileged > >> > assembly > >> > they can get the credentials. The assembly runs as an account that has > >> > privileges in a SQL Server table. > >> > > >> > If I could simply add a strong named assembly to a role for the com+ > >> > app > >> > instead of a user or a group, my trouble would be over. > >> > >> Not really. You would then need to worry about protecting the calling > >> assembly. Even if you use low visibility (private, internal) types and > >> members to handle the credentials processing in this assembly, these > >> would > >> be exposed to any highly privileged code via reflection. > >> > >> > >> > Please help with any thoughts on this matter. It will be much > >> > appreciated. > >> > >> Since you already seem to be comfortable with the idea of using a COM+ > >> application to run in an alternate identity context, have you considered > >> performing the subset of operations that involve actual use of the > >> credentials under a similar COM+ app? If this doesn't seem reasonable, > >> might you be willing to explain how the retrieved credentials actually > >> get > >> used? (It's a lot easier to suggest alternate approaches when one knows > >> the > >> goal as well as the problem. <g>) > >> > >> > >> > > >> > Daren > >> > > >> > >> > >> > >
Thanks for your input, Nicole. I think I will try talking to the network
guys, but it might not be doable given that there are over 50 of these devices distributed around the campus. I will see if they have any input, but I do fear it will come down to a custom program or nothing in the end. Thanks again for your time. [quoted text, click to view] "Nicole Calinoiu" wrote:
> "ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote in message > news:1B654B6E-0EA7-4202-B8A6-A16E9C907660@microsoft.com... > > The device we are connecting to is a control system with a touch panel > > interface. The web server capability of the device allows you to view a > > virtual exact copy of the touch panel interface and control it as if you > > were > > at the device. Basically all we need is to be able to limit the use of > > this > > to a small number of machines in our office. If the credentials are > > known, > > the device could be accessed from anywhere. The web server on the device > > can't be configured to limit access only to certain ip addresses, so we > > thought we should be able to just create a way to automatically pass the > > credentials using a custom interface only installed on the machines that > > need > > the access. > > Might it be possible to use your network to limit the callers rather than > attempting to impose this restriction at either endpoint? For example, > might your internal routing mechanisms allow you to only route traffic to > the device's IP from certain caller IPs? Would adding a firewall or router > between the device and the rest of your network be an acceptable option? > > > > Perhaps it would be better to allow knowledge of credentials and > > limit access to the device to certain hostnames instead, > > Hostnames just map back to IP addresses, except they're even easier to > spoof. If the device doesn't allow caller control based on IP, then chances > are it doesn't allow it based on host name either. > > > but I don't know how > > that can be done. Do you? I'm starting to feel that this may be > > impossible > > but I always hate to have to accept impossibility so I am pressing on > > perhaps > > in futility. Might we implement some sort of intermediary web page on our > > IIS server? This sounds intriguing. > > Creating a pass-through page that's hosted on a server that can limit > callers based on IP address should be quite viable. However, given that > additional programming work would be required, it may be a more expensive > than the network approach. Unless your network admin guys have already > ruled out a network-based approach, it might be a good idea to talk to them > before pursuing anything that requires custom programming... > > > > > > > > "Nicole Calinoiu" wrote: > > > >> "ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote in > >> message > >> news:8B941039-05C0-497B-8F35-B3B83782B7E0@microsoft.com... > >> <snip> > >> > I did consider this, and it seemed perfect until I could not figure out > >> > how > >> > to lauch a browser window in the proper desktop. If I host the com+ > >> > app > >> > as a > >> > service it can be done if I run it as system, but it runs as a specific > >> > user > >> > and I can't figure out the UI context switching I guess using window > >> > stations > >> > or something. Currently over my head. My goal here is to pass the > >> > credentials to a control device that hosts a minimal web server, and > >> > receives > >> > basic authentication over SSL. > >> > >> Do you actually need a browser window for this? Is this not something > >> that > >> could be done, for example, by connecting to the device web server via > >> code? > >> Once authenticated, how is the user intended to interact with the device? > >> > >> > >> > >> > The server can't be configured for > >> > authentication type so I don't know what else to do. > >> > >> To be honest, I doubt that the authentication type would make much > >> difference with respect to your focal problem. > >> > >> > >> > The problem exists > >> > because the credentials can't be known by the users for business > >> > reasons. > >> > >> Hmm... If the credentials are meant to protect the device, and your > >> application grants the user the same level of access to the device, why > >> do > >> you care if the users actually know the credentials or not? (I can see a > >> few potential reasons, but each has a very different first line solution > >> than what you've described so far.) > >> > >> > >> > >> > I think I promised more than I can deliver here. I still have to > >> > figure > >> > out > >> > a safe way to send the credentials to the page on the server, and I > >> > played > >> > with ideas like modifying the security rule that prevents passing > >> > user:password@- type URLs. That can't be good. > >> > >> No, it can't. <g> It also won't really address your central problem, as > >> far as I can tell. > >> > >> > >> > > >> > We might have settled for a way to automate entry of passwords in the > >> > protected storage part of the registry and just let the users see the > >> > username, but I can't figure that out either and it seems like a bad > >> > idea. > >> > > >> > Anyway, I'm rambling now, and this probably just sounds misguided in > >> > the > >> > first place, but if you have any suggestions, then thanks in advance. > >> > > >> > > >> > "Nicole Calinoiu" wrote: > >> > > >> >> "ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote in > >> >> message > >> >> news:10136359-B677-4B44-8941-27EC06730221@microsoft.com... > >> >> > The simple version of my question is this: how can you (or can you) > >> >> > set > >> >> > security so that a privileged assembly can only be called by a > >> >> > specific > >> >> > strong named assembly? > >> >> > >> >> Sort of, but the protection isn't worth much. You can add > >> >> (link)demands > >> >> for > >> >> StrongNameIdentityPermission (or any other identity permission) to the > >> >> target assembly. However, it's quite trivial for highly privileged > >> >> code > >> >> (FullTrust trant or even partial permission set that includes certain > >> >> key > >> >> CAS permissions) to bypass such a demand. In addition, in the v. 2.0 > >> >> framework, all fully trusted assemblies will automatically pass such > >> >> demands, so this approach will no longer protect against even > >> >> unintentional > >> >> misuse of types or members protected by such demands. All in all, not > >> >> exactly worth the bother... > >> >> > >> >> > >> >> > I got hopeful when I found out about the strong name > >> >> > condition for a code group in cas, but now it seems like all you can > >> >> > do > >> >> > with > >> >> > cas is define what an assembly can call and never what can call the
[quoted text, click to view]
"ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote in message news:1B654B6E-0EA7-4202-B8A6-A16E9C907660@microsoft.com... > The device we are connecting to is a control system with a touch panel > interface. The web server capability of the device allows you to view a > virtual exact copy of the touch panel interface and control it as if you > were > at the device. Basically all we need is to be able to limit the use of > this > to a small number of machines in our office. If the credentials are > known, > the device could be accessed from anywhere. The web server on the device > can't be configured to limit access only to certain ip addresses, so we > thought we should be able to just create a way to automatically pass the > credentials using a custom interface only installed on the machines that > need > the access. Might it be possible to use your network to limit the callers rather than attempting to impose this restriction at either endpoint? For example, might your internal routing mechanisms allow you to only route traffic to the device's IP from certain caller IPs? Would adding a firewall or router between the device and the rest of your network be an acceptable option? [quoted text, click to view] > Perhaps it would be better to allow knowledge of credentials and > limit access to the device to certain hostnames instead, Hostnames just map back to IP addresses, except they're even easier to spoof. If the device doesn't allow caller control based on IP, then chances are it doesn't allow it based on host name either. [quoted text, click to view] > but I don't know how > that can be done. Do you? I'm starting to feel that this may be > impossible > but I always hate to have to accept impossibility so I am pressing on > perhaps > in futility. Might we implement some sort of intermediary web page on our > IIS server? This sounds intriguing. Creating a pass-through page that's hosted on a server that can limit callers based on IP address should be quite viable. However, given that additional programming work would be required, it may be a more expensive than the network approach. Unless your network admin guys have already ruled out a network-based approach, it might be a good idea to talk to them before pursuing anything that requires custom programming... [quoted text, click to view] >
> > "Nicole Calinoiu" wrote: > >> "ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote in >> message >> news:8B941039-05C0-497B-8F35-B3B83782B7E0@microsoft.com... >> <snip> >> > I did consider this, and it seemed perfect until I could not figure out >> > how >> > to lauch a browser window in the proper desktop. If I host the com+ >> > app >> > as a >> > service it can be done if I run it as system, but it runs as a specific >> > user >> > and I can't figure out the UI context switching I guess using window >> > stations >> > or something. Currently over my head. My goal here is to pass the >> > credentials to a control device that hosts a minimal web server, and >> > receives >> > basic authentication over SSL. >> >> Do you actually need a browser window for this? Is this not something >> that >> could be done, for example, by connecting to the device web server via >> code? >> Once authenticated, how is the user intended to interact with the device? >> >> >> >> > The server can't be configured for >> > authentication type so I don't know what else to do. >> >> To be honest, I doubt that the authentication type would make much >> difference with respect to your focal problem. >> >> >> > The problem exists >> > because the credentials can't be known by the users for business >> > reasons. >> >> Hmm... If the credentials are meant to protect the device, and your >> application grants the user the same level of access to the device, why >> do >> you care if the users actually know the credentials or not? (I can see a >> few potential reasons, but each has a very different first line solution >> than what you've described so far.) >> >> >> >> > I think I promised more than I can deliver here. I still have to >> > figure >> > out >> > a safe way to send the credentials to the page on the server, and I >> > played >> > with ideas like modifying the security rule that prevents passing >> > user:password@- type URLs. That can't be good. >> >> No, it can't. <g> It also won't really address your central problem, as >> far as I can tell. >> >> >> > >> > We might have settled for a way to automate entry of passwords in the >> > protected storage part of the registry and just let the users see the >> > username, but I can't figure that out either and it seems like a bad >> > idea. >> > >> > Anyway, I'm rambling now, and this probably just sounds misguided in >> > the >> > first place, but if you have any suggestions, then thanks in advance. >> > >> > >> > "Nicole Calinoiu" wrote: >> > >> >> "ubiquitousspor" <ubiquitousspor@discussions.microsoft.com> wrote in >> >> message >> >> news:10136359-B677-4B44-8941-27EC06730221@microsoft.com... >> >> > The simple version of my question is this: how can you (or can you) >> >> > set >> >> > security so that a privileged assembly can only be called by a >> >> > specific >> >> > strong named assembly? >> >> >> >> Sort of, but the protection isn't worth much. You can add >> >> (link)demands >> >> for >> >> StrongNameIdentityPermission (or any other identity permission) to the >> >> target assembly. However, it's quite trivial for highly privileged >> >> code >> >> (FullTrust trant or even partial permission set that includes certain >> >> key >> >> CAS permissions) to bypass such a demand. In addition, in the v. 2.0 >> >> framework, all fully trusted assemblies will automatically pass such >> >> demands, so this approach will no longer protect against even >> >> unintentional >> >> misuse of types or members protected by such demands. All in all, not >> >> exactly worth the bother... >> >> >> >> >> >> > I got hopeful when I found out about the strong name >> >> > condition for a code group in cas, but now it seems like all you can >> >> > do >> >> > with >> >> > cas is define what an assembly can call and never what can call the >> >> > assembly. >> >> > I hope I am just missing something obvious. >> >> >> >> Well, if you keep digging, you may find identity permission demands >> >> advocated for this but, as mentioned above, they're not particular >> >> effective >> >> against deliberate misuse even in the v. 1.x framework. >> >> >> >> >> >> > My goal here is to use the privileged application to return >> >> > credential >> >> > information to the calling program. I can achieve rights elevation >> >> > using >> >> > COM+ and putting a low privileged user in a role for the COM+ app, >> >> > but >> >> > this
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 |