[
https://issues.apache.org/jira/browse/NIFI-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15675659#comment-15675659
]
Andre edited comment on NIFI-3050 at 11/18/16 3:57 AM:
-------------------------------------------------------
+1 to [~joewitt]] comment. Many processors will use other files as input to
certain activities (the upcoming ExtractGrok has the same approach) but I am
not sure we should include them as "restricted" per se. The issue with those I
suspect, would be restricted to error messages that could contain snippets of
the target file. (e.g. using /etc/passwd as ScanContent dictionary could result
in data spill through error messages).
Perhaps one thing we should consider, is the ability to "chroot" paths used by
NiFi processors, that is , to restrict the DFMs to child paths of a particular
directory in the filesystem (the root path would be configured via properties,
similarly to what happens with the zookeeper "chroot").
If we decide to follow this approach, we would have to go around looking at
processors making sure that "File.open" type of operations are wrapped with a
check against the results of [getCanonicalPath or via Security
Manager|https://www.securecoding.cert.org/confluence/display/java/FIO16-J.+Canonicalize+path+names+before+validating+them]
was (Author: trixpan):
+1 to [~joseph Witt] comment. Many processors will use other files as input to
certain activities (the upcoming ExtractGrok has the same approach) but I am
not sure we should include them as "restricted" per se. The issue with those I
suspect, would be restricted to error messages that could contain snippets of
the target file. (e.g. using /etc/passwd as ScanContent dictionary could result
in data spill through error messages).
Perhaps one thing we should consider, is the ability to "chroot" paths used by
NiFi processors, that is , to restrict the DFMs to child paths of a particular
directory in the filesystem (the root path would be configured via properties,
similarly to what happens with the zookeeper "chroot").
If we decide to follow this approach, we would have to go around looking at
processors making sure that "File.open" type of operations are wrapped with a
check against the results of [getCanonicalPath or via Security
Manager|https://www.securecoding.cert.org/confluence/display/java/FIO16-J.+Canonicalize+path+names+before+validating+them]
> Restrict dangerous processors to special permission
> ---------------------------------------------------
>
> Key: NIFI-3050
> URL: https://issues.apache.org/jira/browse/NIFI-3050
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Core Framework
> Affects Versions: 1.0.0
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Priority: Blocker
> Labels: security
> Fix For: 1.1.0
>
>
> As evidenced by [NIFI-3045] and other discoveries (e.g. using an
> {{ExecuteScript}} processor to iterate over a {{NiFiProperties}} instance
> after the application has already decrypted the sensitive properties from the
> {{nifi.properties}} file on disk, using a {{GetFile}} processor to retrieve
> {{/etc/passwd}}, etc.) NiFi is a powerful tool which can allow unauthorized
> users to perform malicious actions. While no tool as versatile as NiFi will
> ever be completely immune to insider threat, to further restrict the
> potential for abuse, certain processors should be designated as
> {{restricted}}, and these processors can only be added to the canvas or
> modified by users who, along with the proper permission to modify the canvas,
> have a special permission to interact with these "dangerous" processors.
> From the [Security Feature
> Roadmap|https://cwiki.apache.org/confluence/display/NIFI/Security+Feature+Roadmap]:
> {quote}
> Dangerous Processors
> * Processors which can directly affect behavior/configuration of NiFi/other
> services
> - {{GetFile}}
> - {{PutFile}}
> - {{ListFile}}
> - {{FetchFile}}
> - {{ExecuteScript}}
> - {{InvokeScriptedProcessor}}
> - {{ExecuteProcess}}
> - {{ExecuteStreamCommand}}
> * These processors should only be creatable/editable by users with special
> access control policy
> * Marked by {{@Restricted}} annotation on processor class
> * All flowfiles originating/passing through these processors have special
> attribute/protection
> * Perhaps *File processors can access a certain location by default but
> cannot access the root filesystem without special user permission?
> {quote}
> [~mcgilman] and I should have a PR for this tomorrow.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
