-
Notifications
You must be signed in to change notification settings - Fork 10
Encrypt SQLite databases from mozStorageService #173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: enterprise-main
Are you sure you want to change the base?
Conversation
| } | ||
|
|
||
| nsresult GetKeyForFile(nsIFile* aFile, nsCString& keyString) { | ||
| nsAutoCString telemetryFilename; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weird naming here.
|
I think this wants tests as well. For Foxfooding we can deal with some flakyness but causing all SQLite databases to get corrupted will probably get old soon for the poor testers 😄 |
4366c03 to
6c41571
Compare
6c41571 to
904029f
Compare
904029f to
8afd65b
Compare
8afd65b to
a0458b4
Compare
security/keystore/Persist.cpp
Outdated
| // PK11SDR_Encrypt will allocate the needed buffer in SECItem | ||
| encryptedKey.reset(new SECItem()); | ||
|
|
||
| stat = PK11SDR_Encrypt(&keyid, key.get(), encryptedKey.get(), nullptr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This uses 3DES. You want PK11SDR_EncryptWithMechanism.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a particular reason to have this in its own directory? These kinds of files tend to belong in security/manager (or at least a subdirectory therein).
| mozilla::UniqueSECItem key = mozilla::UniqueSECItem(new SECItem()); | ||
| SECStatus stat = SECITEM_MakeItem(nullptr, key.get(), | ||
| (unsigned char*)encryptedKey.Data(), | ||
| encryptedKey.Length()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally speaking, you probably don't need to do the whole new SECItem() ... SECITEM_MakeItem(...) - you can do something like SECItem key = { siBuffer, (unsigned char*)encryptedKey.Data(), encryptedKey.Length() }; (assuming the NSS functions you call either copy the data or only borrow it for the length of the call, which is most of them).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That particular example needs a "proper" SECItem (on the heap), because it is later stored in KEY_MAP, which is static and thus outlives encryptedKey. I already tried to reduce buffer allocation, and I'll move to a stack SECItem in the path == SYSTEM_KEY_NAME path, but if I missed anything else do let me know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of this code seems very similar to NSSKeyStore - is there a reason to not re-use that? (currently it's only used as a fallback on Linux, but you could use it unconditionally here)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For one the custom solution allows us some flexibility right away, only requiring the token to be unlocked once for loading all the keys. Later database open operations can then rely on the master key to do their work (create new key, decrypt existing key). Additionally, there is a plan to turn the keystore into the lockstore module which Benjamin has been working on.
a0458b4 to
788f472
Compare
788f472 to
1190b4e
Compare
Encrypt SQLite database whose connections are created in mozStorageService. Cloned and
ATTACHed connections are also affected. The mechanism is behind a newsecurity.storage.keystore.enabled. The keys for the connections are stored, encrypted by the SDR, in a newbikeshed/keystore.enc.