Edit: DJANGO_SETTINGS_MODULE isn't relative, it will import any arbitrary module you give it. If we accept that then I think we are accepting the risk of imports via an attacker controlling environment variables whilst Django starts up?
On Sat, May 27, 2017 at 8:49 PM, Tom Forbes <t...@tomforb.es> wrote: > > I'm wary of possible security ramifications: if we do this, changing a > configuration value will import an arbitrary module, which could make it > easier to run arbitrary code in some scenarios. I don't have a clear threat > model in mind here, though. > > Good point, it's not wise to enable this even without a clear threat > model. Django does import the settings based on an environment variable, > but it's relative and if you can use that to do anything nasty then you're > most likely already through the airtight hatch (so to speak). However > importing potentially global modules could be bad news. > > Ignoring it is always an option, but could we not specify that the third > party database provider has to be in the `INSTALLED_APPS`? That could > provide some form of whitelisting so not any old module is imported. Not > sure about any issues that may arise from this though. > > > One possibility would be to use entrypoints in setuptools, this way 3rd > party backends could specify a name which then has a fixed & verified > import path. > > This seems like it could get complex, and be quite unlike anything else in > Django. > > Perhaps just supporting this for first-party database backends is easiest? > > On Thu, May 25, 2017 at 8:46 AM, Aymeric Augustin <aymeric.augustin@ > polytechnique.org> wrote: > >> Hello, >> >> I'm wondering what the exact definition of the URL format is. Is it >> specified somewhere? Or is it just: >> >> [engine]://[username]:[password]@[host]:[port]/[name] >> >> where we create arbitrary [engine] values in an ad-hoc fashion? >> >> On 24 May 2017, at 21:21, Tom Forbes <t...@tomforb.es> wrote: >> >> My two cents: connection strings/database URI's are a feature I've sorely >> missed in Django. >> >> Built-in functionality to convert environment variables like >> DJANGO_DB_DEFAULT (or more generally DJANGO_DB_*key*) into the relevant >> DATABASE setting would make some deployment situations a lot simpler. >> Currently, unless you use dj-database-uri you have to define a bunch of >> ad-hoc DB_USER/DB_PASSWORD etc env variables and price the dictionary >> together yourself. >> >> >> Fully agreed. While relatively minor, it's an annoyance. >> >> How does this library complex keys like OPTIONS, TEST or DEPENDENCIES? >> >> >> I don't think it's reasonable to cram them in a URL. >> >> dj-database-url allows passing options as extra keyword arguments. Other >> values should be explicitly added in the settings module, by updating the >> dict generated from the URL. >> >> To help support third part backends: perhaps the scheme portion of the >> URI could be either a relative import from django.db.backends or an >> absolute import to a third party library? It seems URI schemes can have >> dots and underscores in them, so they can be python package paths. >> >> I.e sqlite3://xyz would resolve go django.db.backends.sqlite3, but >> sqlserver_ado://xyz would resolve to the third party django-mssql engine >> via an absolute import. >> >> >> I'm wary of possible security ramifications: if we do this, changing a >> configuration value will import an arbitrary module, which could make it >> easier to run arbitrary code in some scenarios. I don't have a clear threat >> model in mind here, though. >> >> I'd rather specify the database engine explicitly when calling >> dj-database-url if it's a third-party engine. There's an open question >> about what to do with the [engine] part of the URL in that case. Ignoring >> it entirely is the easiest. >> >> Best regards, >> >> -- >> Aymeric. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> Visit this group at https://groups.google.com/group/django-developers. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/django-developers/A0870D90-75DE-496B-A838-AC7D7488A67D% >> 40polytechnique.org >> <https://groups.google.com/d/msgid/django-developers/A0870D90-75DE-496B-A838-AC7D7488A67D%40polytechnique.org?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJN80HNFnKkZQ5rFaoH5jqiEBFSfdYZpqCrw0C0E-q9f_w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
