I'm looking for links, or an answer here, on to how to properly configure the database permissions to secure a Django app? To be clear, I'm looking specifically for material dealing with grants on the database, not permissions within the Django framework itself.
+1
A:
I usually:
grant all privileges on my_db.* to my_user@localhost identified by 'my_user_pass'
grant all privileges on test_my_db.* to my_user@localhost identified by 'my_user_pass'
I suppose if there were a bug in django, you might be opening your database up to terrible things, but you'd have other problems if there were that big of a security hole in django.
django minimally needs select, insert, update, and delete, to operate. If you're using test or syncdb at all, you'll also need to be able to create tables, and indexes (and maybe the file permission for loading sql fixtures).
So, for a mysql db, I'd guess the optimal set of permissions might be select, insert, update, delete, create, index, and file. If you wanted to get real nitty-gritty, you could selectively grant these permissions as appropriate on the table level (rather than the db level).
Personally, I find grant all ... easier to type.
Seth
2010-02-24 00:13:49
Thanks Seth. I do that too. However, I was looking for the "real nitty-gritty" as you put it. I saw something on the web a while back that covered this in detail and seemed like worthwhile hardening. Regrettably I didn't bookmark it...
emru
2010-02-24 00:38:37
This goes without saying, but after the above: `flush privileges;`
mlissner
2010-08-14 02:44:24
A:
What's the purpose of configuring permissions on DB level? If your server is compromised then the attacker will be able to do anything with your database (because he has the login/pass) and permissons won't help. If your server is secured then permissions are useless.
Permissions can make sense if your DB server is available from the outer world, but it is not a good idea to do so.
Mike Korobov
2010-02-24 15:42:37
By adding DB permissions you have an opportunity to limit what can be achieved with an SQL injection etc attacks. If the web server is compromised DB permissions have the potential to limit the damage - e.g. there likely isn't any reason for the web app login to be able to drop the database etc.
emru
2010-02-24 21:20:09
SQL injections are easy to avoid with django and I don't see a big difference between clearing all the tables and dropping the database. In either way you have your data lost and should restore anything from backup after eliminating the vulnerability. It is not obvious that DB-level permissions make your project more secure. I think that django doesn't have built-in support for DB-level permissions because it's better to put efforts in fixing real problems: XSS, CSRF, SQL injections, etc. and not to fool yourself with half measures.
Mike Korobov
2010-02-25 03:59:09
Here's Microsoft's advice for ASP.NET apps "...Grant only the minimum permissions that the application must have to function."And SANS "... The approach to this should be to grant only the minimum permissions the application requires to run."Etc Flaws can be at any level in the application stack - why wouldn't you want to use every possible tool to prevent an attack propagating.
emru
2010-02-25 04:27:42
These are good advices. Running you web server with root permissions is a very bad idea indeed. Having separate unix and DB users for different sites on the same server is a great idea. In many cases this can help. But I don't see how grained DB-level permissions can help. If attacker is successful with something on lower level than django or on django level then he has at least the same permissions as django instance so he can trash the DB.
Mike Korobov
2010-02-25 06:15:50
Or not if the django db connection has restricted rights. BTW the two quotes above relate specifically to DB permissions for web apps.
emru
2010-02-25 08:43:31