Given that we only run in full trust anyway, it's fine. If we were up to consider transparency, we should mark these classes/constructor as critical as they access machine data (env variables).
On Thu, Mar 5, 2009 at 3:17 AM, Jonathon Rossi <[email protected]> wrote: > Hey Hammett, > > I'm interested to hear where you think there is security implications for > this patch. I could be completely overlooking an issue with it. > > On Mon, Mar 2, 2009 at 9:52 PM, Jonathon Rossi <[email protected]> wrote: >> >> That is what I was thinking. >> >> However, we probably should be demanding read access for the >> EnvironmentPermission for cases where Castle assemblies are installed in the >> GAC and APTCA is used. >> >> On Mon, Mar 2, 2009 at 9:33 PM, James Curran <[email protected]> >> wrote: >>> >>> I don't believe so. To exploit this, one would have to be able to >>> change a environment variable, change something which uses a URI (like >>> a view), or convince a user to run a hostile castle-based exe on their >>> system. In all three cases, the system is already compromised. >>> >>> -- >>> Truth, >>> James >>> >>> On Mon, Mar 2, 2009 at 1:15 AM, hammett <[email protected]> wrote: >>> > >>> > Isnt there security implications on this one? >>> > >>> > On Sun, Mar 1, 2009 at 2:57 AM, <[email protected]> >>> > wrote: >>> >> - Applied Eric Hauser's patch fixing CORE-ISSUE-22 >>> >> "Support for environment variables in resource URI" >>> >>> >> >> >> >> -- >> Jono > > > > -- > Jono > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
