Re: how to deploy python/django application in debian/apache?

On Wed, Feb 10, 2016 at 10:57:29AM -0800, James Schneider wrote:
> On Wed, Feb 10, 2016 at 7:15 AM, Fred Stluka <fred@bristle.com> wrote:
>
> > On 2/10/16 4:37 AM, James Schneider wrote:
> >
> > ... make sure that the Apache system user has read access to that
> > directory and all subdirectories, and no write access ...
> >
> > James,
> >
> > Won't that prevent Django from creating *.pyc files from the
> > deployed *.py files? Or do you suggest deploying *.pyc files?
> >
> > --Fred
> >
>
> Oh, yep, you're right. It was 1:30am and I was in PHP mode in my head (I'm
> not getting kicked off the list for mentioning that word, right? ;-D). I
> believe that means that the Apache user needs write access to the project
> folders (to create the .pyc files), but still only needs read access to the
> .py files. I believe that you can tweak the write access to the .pyc files
> and parent folders after they have been generated by mod_wsgi/Apache. You
> can also do a deployment just using just the .pyc files, if I remember
> correctly.
>
> Thanks for the double-check.
>
> -James

I'm not entirely convinced this is the best idea, to be honest. Sure,
it might be possible, but I fail to see the benefit you get out of
that, compared to just granting the apache user full write access.

If the user has read-only access to *.py files, but read-write access
to *.py[co], a hypothetical attacker with the ability to write to
arbitrary files in your filesystem could just write bytecode directly
to the bytecode files instead of writing plaintext to sources, with
the same effect (which is arbitrary code execution).

The only benefit you get out of it is a much more complicated set of
permissions on your files that will make your life harder to set up
correctly, and easy to mess up, thus potentially breaking the
application in subtle ways. (Unless, of course, there's some scenario
that I'm overlooking, which is perfectly possible.)

I see several options:

* You can decide you don't need the startup speed benefits of having
pre-compiled bytecode files, just deploy read-only source files. As
long as your application server (mod_wsgi?) runs in long-lived
processes, the bytecode files only really play any role on startup,
when everything gets imported, and might make the difference of, I
don't know, a second, tops (unless you have *really* many Python
modules that get imported on startup – take this as a very rough
estimate, and try to measure the difference for yourself instead of
taking my word for it). If that delay is acceptable to you, just
ignore bytecode files.

* You could generate bytecode files beforehand as part of your
deployment infrastructure (for example when generating the
package you install on your servers), and install them read-only
along with the plaintext source files. For example, if you use pip
to install your application on your servers, it will create *.pyc
files automatically with the --compile flag [1].

* You could decide that creating this particular layer of defense
against an attacker with the ability to write to arbitrary files is
not worth it, and just go full read-write. It really depends on the
security requirements and trade-offs you're willing to accept.

In one project, we're going with the second option, where we build
DEB/RPM packages, and include all bytecode files inside those
packages, only writable by root, while the application runs as a
separate user. In other projects we just create a separate user for
every application we deploy, and run those applications from those
users' home directories (where they are checked out from their git
repositories).

Cheers,

Michal


[1]: https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption--compile

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/20160210200258.GI2245%40koniiiik.org.
For more options, visit https://groups.google.com/d/optout.