2009/12/19 Jason Garber <[email protected]>: > I'm pretty sure he is talking about protecting the data in the event that > his `apache` (or similar) user is "owned" by a serious problem in the the > any component of the software stack (OS, apache, mod_wsgi, application, > libraries, etc...).
Maybe, maybe not. They only seemed worried about this one configuration file. Not knowing what the configuration file contains does make it a bit harder to suggest options. FWIW, if wanting a measure of separation so that a breached application can do little harm, there are a progression of steps one could take. 1. Run application in daemon mode as a distinct UNIX user/group where the only reason that user account exists is to run that application. 2. Lock down filesystem privileges so that UNIX user/group is quite limited on what they can access. 3. Use feature of mod_wsgi 3.0 to force a specific daemon process group to run in a chroot jail. 4. Partition the application so that anything dependent on sensitive code or configuration runs in a separate backend process outside of the chroot jail or even on a separate box and use something like XML-RPC or other interprocess communications protocol to talk to it. And yes I know that the chroot support in daemon mode isn't documented except to extent it is mention in the changes file in WIKI. Graham > On Fri, Dec 18, 2009 at 9:20 AM, Brochester L <[email protected]> wrote: >> >> I have another solution the variables returned by globals() is >> writable to the lowest namespaced module. I believe that using a >> simple script inside of the web servers user is a broader arrangement. >> in your main module add something like: >> globals().update({'__builtins__':thisUsersPrototypes}) >> in that users file access routine handlers add: >> fileFor=UserRightsDB.get(thisSession)&FilePermissions >> if not fileFor: >> return([400,Headers]) >> you will find that the user has limited or no access outside of that >> namespace unless redirected by an admin. Simple way. >> >> On 12/14/09, Jason Garber <[email protected]> wrote: >> > On Mon, Dec 14, 2009 at 2:42 AM, amvtek <[email protected]> wrote: >> > >> > >> >> Main risk we are trying >> >> to mitigate, is the one of an 'exploit' on application, at the end of >> >> which the attacker will have gained the privileges of application >> >> effective user. If 'private file' is directly owned by this user, the >> >> attacker would be in position to read it. >> > >> > >> > Hi Amvtek, >> > >> > The problem you are trying to solve is common in our field. What type >> > of >> > data are you trying to protect? >> > >> > -JG >> > >> > -- >> > >> > You received this message because you are subscribed to the Google >> > Groups >> > "modwsgi" 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/modwsgi?hl=en. >> > >> > >> > >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "modwsgi" 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/modwsgi?hl=en. >> >> > > -- > > You received this message because you are subscribed to the Google Groups > "modwsgi" 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/modwsgi?hl=en. > -- You received this message because you are subscribed to the Google Groups "modwsgi" 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/modwsgi?hl=en.
