Improving the NiFi security model

[Andre <an...@fucs.org>]

All,

As I have been working around restricting the level of filesystem
privileges required by NiFi to run, I started to wonder how to tackle what
in my opinion is one of the biggest challenges around NiFi:

How to ensure the ExecuteProcessors, FS processors (GetFile/PutFile) aren't
misused by a rogue DFM.


So that we are all in the same page, in theory it is possible for a rogue
DFM with enough privileges (i.e. right to modify the flow), to overtake a
NiFi environment completely: To achieve this, the attacker would:

Step 1 - use PutFile to overwrite configuration files, in this case, the
XML files with the access policies.
Step 2 - use ExecuteScript ro restart the NiFi process[1]

Given both NiFi and the ExecuteScript run as NiFi user, a security obsessed
admin would have to use remove the processors, or use SELinux or similar
technology to prevent the above scenario from happening.


In light of that I have a few ideas I would like to share:


1 - Allow some processors to be marked as "privileged processors". This
would cover processors that can make changes to the local system (ListFile,
PutFile, GetFile, ExecuteScript, etc).

2 - Create an explicit privilege to control access to these "privileged
processors".


With 1 and 2 in place, Admins would be alerted to the impact of providing
access to certain processors to their users.

In addition, I would suggest the following:

3 - Consider segregating privileges within NiFi:

As far as I understand, once the sudo_cmd_prefix is determined, NiFi will
run its components as the run.as UID. Perhaps we could:

a) Leverage MiNiFi and spin up JVMs to be used to run the privileged
processors listed above.

This of this as a "minifi container".

b) Ensure user access control and processors are run under different UIDs,
preventing the need of having the run.as user acessing the authentication
files (e.g. conf/users.xml)



Keen to hear your thoughts



[1] I realize ExecuteScript could also be used to overwrite files in the FS.

Re: Improving the NiFi security model

[Andre <an...@fucs.org>]

Andy,

We are on the same page about the annotation and the surface of attack. I
didn't want to list item by item but as you highlighted, when using a
single user to run privileged sections of code and user land, everything is
up for grabs.

Unless someone opposes I will be happy to raise a JIRA for the annotation
and another one for the permissions.



Regarding encapsulation, the idea is still quite incipient but I am keen to
keep the ball rolling.

Leaving aside the lack of integration, I wonder what would be the current
limitations and dependencies of adopting such approach today? Is it correct
to assume running some MiNiFi instances would be akin to have a number o
NiFi instance f per entity (user, group, company, etc) talking with NiFi
instances managed by other parties?

Kind regards




On Tue, Oct 4, 2016 at 2:24 PM, Andy LoPresto <al...@apache.org> wrote:

> Andre,
>
> I really like you starting this conversation. I think the
> PrivilegedProcessor annotation/marking and separate permission would be
> valuable, with the understanding that it’s addressing a specific threat —
> malicious DFM. Those processors can (even now) also modify the provenance,
> flowfile, and content repositories, the user database, the authorizations
> files, even nifi.properties directly. They could also be used to
> surreptitiously replace a NAR or some code being run within NiFi. So I see
> a lot of value in locking that down further.
>
> I would want to discuss using MiNiFi to encapsulate privileged processors
> further because of interdependencies on controller services, etc. but it is
> certainly a novel approach and could be successful.
>
> Thanks for bringing these important issues to the list. Insider threat has
> traditionally not been the focus because there are so many attack vectors
> for a malicious admin or DFM to directly cause harm. I think we are at a
> stage as a community where more attention can be paid to these concerns and
> steps taken to mitigate them.
>
>
> Andy LoPresto
> alopresto@apache.org
> *alopresto.apache@gmail.com <al...@gmail.com>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Oct 3, 2016, at 7:56 PM, Andre <an...@fucs.org> wrote:
>
> All,
>
> As I have been working around restricting the level of filesystem
> privileges required by NiFi to run, I started to wonder how to tackle what
> in my opinion is one of the biggest challenges around NiFi:
>
> How to ensure the ExecuteProcessors, FS processors (GetFile/PutFile) aren't
> misused by a rogue DFM.
>
>
> So that we are all in the same page, in theory it is possible for a rogue
> DFM with enough privileges (i.e. right to modify the flow), to overtake a
> NiFi environment completely: To achieve this, the attacker would:
>
> Step 1 - use PutFile to overwrite configuration files, in this case, the
> XML files with the access policies.
> Step 2 - use ExecuteScript ro restart the NiFi process[1]
>
> Given both NiFi and the ExecuteScript run as NiFi user, a security obsessed
> admin would have to use remove the processors, or use SELinux or similar
> technology to prevent the above scenario from happening.
>
>
> In light of that I have a few ideas I would like to share:
>
>
> 1 - Allow some processors to be marked as "privileged processors". This
> would cover processors that can make changes to the local system (ListFile,
> PutFile, GetFile, ExecuteScript, etc).
>
> 2 - Create an explicit privilege to control access to these "privileged
> processors".
>
>
> With 1 and 2 in place, Admins would be alerted to the impact of providing
> access to certain processors to their users.
>
> In addition, I would suggest the following:
>
> 3 - Consider segregating privileges within NiFi:
>
> As far as I understand, once the sudo_cmd_prefix is determined, NiFi will
> run its components as the run.as UID. Perhaps we could:
>
> a) Leverage MiNiFi and spin up JVMs to be used to run the privileged
> processors listed above.
>
> This of this as a "minifi container".
>
> b) Ensure user access control and processors are run under different UIDs,
> preventing the need of having the run.as user acessing the authentication
> files (e.g. conf/users.xml)
>
>
>
> Keen to hear your thoughts
>
>
>
> [1] I realize ExecuteScript could also be used to overwrite files in the
> FS.
>
>
>

Re: Improving the NiFi security model

[Andy LoPresto <al...@apache.org>]

Andre,

I really like you starting this conversation. I think the PrivilegedProcessor annotation/marking and separate permission would be valuable, with the understanding that it’s addressing a specific threat — malicious DFM. Those processors can (even now) also modify the provenance, flowfile, and content repositories, the user database, the authorizations files, even nifi.properties directly. They could also be used to surreptitiously replace a NAR or some code being run within NiFi. So I see a lot of value in locking that down further.

I would want to discuss using MiNiFi to encapsulate privileged processors further because of interdependencies on controller services, etc. but it is certainly a novel approach and could be successful.

Thanks for bringing these important issues to the list. Insider threat has traditionally not been the focus because there are so many attack vectors for a malicious admin or DFM to directly cause harm. I think we are at a stage as a community where more attention can be paid to these concerns and steps taken to mitigate them.


Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Oct 3, 2016, at 7:56 PM, Andre <an...@fucs.org> wrote:
> 
> All,
> 
> As I have been working around restricting the level of filesystem
> privileges required by NiFi to run, I started to wonder how to tackle what
> in my opinion is one of the biggest challenges around NiFi:
> 
> How to ensure the ExecuteProcessors, FS processors (GetFile/PutFile) aren't
> misused by a rogue DFM.
> 
> 
> So that we are all in the same page, in theory it is possible for a rogue
> DFM with enough privileges (i.e. right to modify the flow), to overtake a
> NiFi environment completely: To achieve this, the attacker would:
> 
> Step 1 - use PutFile to overwrite configuration files, in this case, the
> XML files with the access policies.
> Step 2 - use ExecuteScript ro restart the NiFi process[1]
> 
> Given both NiFi and the ExecuteScript run as NiFi user, a security obsessed
> admin would have to use remove the processors, or use SELinux or similar
> technology to prevent the above scenario from happening.
> 
> 
> In light of that I have a few ideas I would like to share:
> 
> 
> 1 - Allow some processors to be marked as "privileged processors". This
> would cover processors that can make changes to the local system (ListFile,
> PutFile, GetFile, ExecuteScript, etc).
> 
> 2 - Create an explicit privilege to control access to these "privileged
> processors".
> 
> 
> With 1 and 2 in place, Admins would be alerted to the impact of providing
> access to certain processors to their users.
> 
> In addition, I would suggest the following:
> 
> 3 - Consider segregating privileges within NiFi:
> 
> As far as I understand, once the sudo_cmd_prefix is determined, NiFi will
> run its components as the run.as UID. Perhaps we could:
> 
> a) Leverage MiNiFi and spin up JVMs to be used to run the privileged
> processors listed above.
> 
> This of this as a "minifi container".
> 
> b) Ensure user access control and processors are run under different UIDs,
> preventing the need of having the run.as user acessing the authentication
> files (e.g. conf/users.xml)
> 
> 
> 
> Keen to hear your thoughts
> 
> 
> 
> [1] I realize ExecuteScript could also be used to overwrite files in the FS.