ctubbsii commented on pull request #1968:
URL: https://github.com/apache/accumulo/pull/1968#issuecomment-810580911
> > var decryptionContext =
createRFileDecryptionContextForTableFromFileAndConfig({tableName, tableConfig,
decryptParams});
>
> I was wondering what the user should put in `tableConfig` for decryption.
Should it be a list of classes to use for decryption? That is where I was going
with this PR... User sets
`table.crypto.decrypters=CryptoClassA,CryptoClassB,OldCrypto`. Then when we
read the decryptParams like you have:
>
> > var decryptParams = encryptedRFile.readCryptoHeader(file);
>
> We look at the class name written in the `decryptParams` and see if it
matches one of the classes configured in `table.crypto.decrypters`.
The user shouldn't be configuring the decrypter class at all. That's too
low-level to be convenient for users. The CryptoService should make that
decision. Users should be configuring options that are CryptoService-dependent
in `table.crypto.opts.*`. The CryptoService implementation that users configure
for the system would be responsible for documenting what options are available
and what they do.
>
> Asked in another way... How do we prevent user from writing code that does
bad things? Aka..
>
> @Override
> public FileDecrypter getFileDecrypter(CryptoEnvironment env) {
> //load class bad class name
> var decryptParams = env.getDecryptParams();
> String maliciousClassName = decryptParams.getClassName();
> return loadClass(maliciousClassName);
> }
That would be the responsibility of the CryptoService implementation itself
to guard against. A good implementation of the CryptoService won't have options
to specify arbitrary class names to use, but will do something more sensible...
like provide options for the crypto algorithm, and it will instantiate its own
decrypter implementation based on the algorithm selected.
We can't protect against users deploying a bad CryptoService implementation
though. The responsibility is on them to deploy only dependencies they trust,
including implementations of pluggable Accumulo components shipped in separate
jars.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
