[ 
https://issues.apache.org/jira/browse/NIFI-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673399#comment-15673399
 ] 

Anders Breindahl commented on NIFI-2656:
----------------------------------------

Missed this one.

Considering that passing a {{-k}} on the command line is a world-viewable way 
of doing this, proposed solutions only need to improve on that.

Inenvitably, without a drop-privilege feature in a JVM (right?), we cannot 
avoid after-startup readability of something that was readable during startup. 
And the start of key management has to start with an un-encrypted property 
somewhere. (And if your policies don't allow such on disk, that may be "on your 
keyboard").

Thus, we need to have the secret sitting in a file owned by a more privileged 
user (root, presumably), passed to the {{su}}'ed/{{sudo}}'ed JVM in some 
manner, and not be accessible after that.

How about:

- Having the startup script (which is run as root until it {{sudo -u 
runasuser}}'es) place the secret key in a file, {{chmod 0600}}/{{chown 
runasuser:}} that, and have {{NiFi}} (the main class) delete/shred the file 
once read?
-- This at least makes the {{nifi.bootstrap.sensitive.key}} invisible to NiFi 
processors. That is, as long as it is a precondition for NiFi to reach service 
level that this file is gone.
- Alternatively, a fifo could be opened, by root, and allow the secret to be 
read only once.
-- This could be done in the init script after spawning {{RunNifi}}.
-- {{NiFi}} could wait for this file to become accessible.

Also; for any such operation, it would be prudent to have NiFi assert proper 
permissions on secret files. I.e. the startup script should err out, if they 
were improper, so people don't inadvertently wind up in insecure configurations.

All of the above merely brainstorming, and I haven't given any thought to 
cross-platform compatibility. Let me know what you are thinking. :)

> Allow bootstrap process to prompt for password/key
> --------------------------------------------------
>
>                 Key: NIFI-2656
>                 URL: https://issues.apache.org/jira/browse/NIFI-2656
>             Project: Apache NiFi
>          Issue Type: New Feature
>          Components: Configuration, Core Framework
>    Affects Versions: 1.0.0
>            Reporter: Andy LoPresto
>            Assignee: Andy LoPresto
>            Priority: Minor
>              Labels: bootstrap, config, encryption, security
>             Fix For: 1.2.0
>
>
> The bootstrap process {{RunNiFi.java}} is currently responsible for reading 
> the key from {{bootstrap.conf}} and sending it to the running NiFi process 
> {{NiFi.java}} to be used for sensitive property decryption. This exposes the 
> key in two places:
> * Plaintext in {{bootstrap.conf}}
> * In the process invocation
> Running the following command ({{ps -aef | grep -i nifi}}) will result in the 
> following output:
> {code}
> ...
>   501 11597 11596   0  6:51PM ttys001    0:08.55 
> /Users/alopresto/.jenv/versions/1.8/bin/java -classpath 
> /Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./conf:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/bcprov-jdk15on-1.54.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/commons-lang3-3.4.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/jcl-over-slf4j-1.7.12.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/jul-to-slf4j-1.7.12.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/log4j-over-slf4j-1.7.12.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/logback-classic-1.1.3.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/logback-core-1.1.3.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/nifi-api-1.0.0-SNAPSHOT.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/nifi-documentation-1.0.0-SNAPSHOT.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/nifi-framework-api-1.0.0-SNAPSHOT.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/nifi-nar-utils-1.0.0-SNAPSHOT.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/nifi-properties-1.0.0-SNAPSHOT.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/nifi-properties-loader-1.0.0-SNAPSHOT.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/nifi-runtime-1.0.0-SNAPSHOT.jar:/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./lib/slf4j-api-1.7.12.jar
>  -Dorg.apache.jasper.compiler.disablejsr199=true -Xmx512m -Xms512m 
> -Dsun.net.http.allowRestrictedHeaders=true -Djava.net.preferIPv4Stack=true 
> -Djava.awt.headless=true -XX:+UseG1GC 
> -Djava.protocol.handler.pkgs=sun.net.www.protocol 
> -Dnifi.properties.file.path=/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/./conf/nifi.properties
>  -Dnifi.bootstrap.listen.port=58213 -Dapp=NiFi 
> -Dorg.apache.nifi.bootstrap.config.log.dir=/Users/alopresto/Workspace/nifi/nifi-assembly/target/nifi-1.0.0-SNAPSHOT-bin/nifi-1.0.0-SNAPSHOT/logs
>  org.apache.nifi.NiFi -k 
> 0123456789ABCDEFFEDCBA98765432100123456789ABCDEFFEDCBA9876543210
> ...
> {code}
> To allow for a more secure invocation, the NiFi process could pause and 
> prompt for the password/key entry in a secure console if it is not provided 
> in the invocation arguments from bootstrap (or if a special flag is 
> provided). While this would require manual intervention to start the process, 
> it would not be default behavior. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to