> and root seems (unsurprisingly) able to do anything desired with the > database. He meant that root wouldn't be able to read the database if the database was encrypted. But, again, the question is whether root would have access to the encryption keys. If the django user has access to the encryption keys, root also does.
What I'm getting at is that the benefits of encrypting the database are questionable. Maybe there is some edge case in which it would be useful. I am no security specialist, but the thing is, unless you are a security specialist and really know what you are doing, encrypting your database would probably not achieve much, or it might even make things worse. Antonis Christofides http://djangodeployment.com On 2017-05-08 20:40, Tim Chase wrote: > On 2017-05-08 18:26, Melvyn Sopacua wrote: >>> What would you gain by encrypting it? >> Three things: >> 1) If the file gets deleted, Django does not recreate it with that >> mode. Solvable by using a dedicated directory instead of the above. > I'm not sure I see this as a benefit, but if rogue processes are > deleting your database, the permissions upon recreation would be the > least of my worries. ;-) > >> 2) root can't do anything with it nor can daemons that are >> compromised before switching to unprivileged user. > You sure about this? I just tested the scenario: > > $ su - > Password: > root@laptop:~# sqlite3 test.db > SQLite version 3.8.7.1 2014-10-29 13:59:56 > Enter ".help" for usage hints. > sqlite> create table example (id int); > sqlite> insert into example values (42); > sqlite> select * from example; > 42 > sqlite> > root@laptop:~# chown tim:tim test.db > root@laptop:~# chmod 600 test.db > root@laptop:~# ls -lsF test.db > 4 -rw------- 1 tim tim 2048 May 8 12:33 test.db > root@laptop:~# sqlite3 test.db > SQLite version 3.8.7.1 2014-10-29 13:59:56 > Enter ".help" for usage hints. > sqlite> select * from example; > 42 > sqlite> delete from example; > sqlite> > > and root seems (unsurprisingly) able to do anything desired with the > database. > >> 3) Additional layer in case martians invade earth and other things >> that should not happen. Not uncommon in high-security environments >> to defend against the unknown. See for example the requirements >> FIPS-140[1] places on access to cryptographic keys, even though we >> all put them in a directory mode 500 owned by root. > While conceivable, you still have to have the decryption keys > available to the Django process to be able to decrypt the values. > Theoretically, one could load the keys off a removable device into a > single Django process, then unmount/remove the external device. But > if you have Django processes spinning up with load increase, you'd > have to have the keys available to them. > > Otherwise, as a recent "whoops, I deleted my source code, so I > salvaged it from the process that was currently running that code" > article[1] suggests, one can also attach to a running process that > would grant access to the decrypting keys in memory, even if the > theoretical external device has been removed. > > Security is hard. :-) > >> But I feel we're going off-topic now. > Maybe, maybe not. :-) > > -tkc > > > [1] https://gist.github.com/simonw/8aa492e59265c1a021f5c5618f9e6b12 > > > > > -- 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+unsubscr...@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/fc46dd1d-d370-51c2-6099-9dc5cdc0e39b%40djangodeployment.com. For more options, visit https://groups.google.com/d/optout.
