nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre <andre-li...@fucs.org>
Subject Re: Improving the NiFi security model
Date Wed, 05 Oct 2016 12:51:35 GMT
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 <alopresto@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 <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 <andre-lists@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.
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message