[
https://issues.apache.org/jira/browse/NIFI-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140369#comment-15140369
]
Andre edited comment on NIFI-1461 at 2/10/16 7:04 AM:
------------------------------------------------------
[~joewitt]
May I suggest we hold this to 0.6.0 ?
I strongly suspect we may be moving too fast.
The main challenge we have is to run nifi.sh after installing from RPM. This is
what we must solve in this patch.
But we should do this without affecting the overall security of the resulting
system. So I took my dusted hat from the basement and tried to think from a
basic threat model perspective.
I can see a few basic issues we should try to avoid (this list is certainly not
extensive, just what come to my mind immediately).:
* *Scenario 1*: local unauthorised users (i.e. people outside the DFM role)
from tainting a NiFi setup.
* *Scenario 2*: remote users who can compromise nifi by an hypothetical
vulnerability from escalating privileges using the access to the NiFi user.
h2. Scenario 1
Possible approach
- No folder under the nifi install should be writeable by individuals other
than root or nifi (where applicable).
- It is imperative to note that write permissions should be granted only where
required by nifi. As an example, giving nifi write permissions to
{{conf/flow.xml.gz}} is required while giving write permissions to
{{conf/bootstrap.conf}} is not.
h2. Scenario 2:
This is a tricky one but I can try to address at least the cases I witnessed
during my pen-testing years (long long long time ago). I assume that an
hypothetical bug in nifi gave an unauthorised party access to the system shell
(under nifi UID and GID) and no config management/integrity check mechanism is
in use.
h3. Scenario 2.a - {{conf/bootstrap.conf}} is writeable by nifi
This is a particular case that I witness far too many times (usually around the
deployment of DBMS but also the good old Apache HTTP server):
The intruder (but also the rogue DFM) modify {{run.as}} setting and wait for a
service restart as the desired user. Using a crafted script run through
*ExecuteScript* processor to obtain full root access.
h3. Scenario 2.b - Folders are writeable by nifi
One of my favourites.
Because of the way Unix filesystem permissions work, a user that has write
permission to directory is able to move files, even though sometimes it may be
unable to write the file itself.
Therefore the traditional to play around this situation is to move the target
file (i.e. rename {{bootstrap.conf}} ) and write a new one in its place and
then it is back to scenario 2.a
Attack would be like (where trixpan is the original {{run.as}} user)
{code}
$ ls -al
total 12
drwxr-xr-x 2 trixpan trixpan 4096 Feb 10 17:23 .
drwxr-xr-x 20 trixpan trixpan 4096 Feb 10 17:22 ..
-rw-r--r-- 1 root root 4 Feb 10 17:23 root_owns
$ echo bbb >> root_owns
-bash: root_owns: Permission denied
$ mv root_owns moved_root_owns
$ ls -al
total 12
drwxr-xr-x 2 trixpan trixpan 4096 Feb 10 17:23 .
drwxr-xr-x 20 trixpan trixpan 4096 Feb 10 17:23 ..
-rw-r--r-- 1 root root 4 Feb 10 17:23 moved_root_owns
$ cat moved_root_owns > root_owns
$ ls -al
total 16
drwxr-xr-x 2 trixpan trixpan 4096 Feb 10 17:26 .
drwxr-xr-x 20 trixpan trixpan 4096 Feb 10 17:23 ..
-rw-r--r-- 1 root root 4 Feb 10 17:23 moved_root_owns
-rw-r--r-- 1 trixpan trixpan 4 Feb 10 17:26 root_owns
{code}
h4. Scenario 2.b.i - {{lib}} is writeable by nifi
Intruder (or rogue DFM) replace a NAR file that can compromise the
confidentiality of the data flowing through NiFi (e.g. the PutS3 processor also
send data to intruder S3 buckets)
h4. Scenario 2.b.ii - {{bin}} is writeable by nifi
Intruder modifies {{nifi.sh}} to run whatever it wants whenever the service is
restarted (i.e. before {{sudo -u $\{run_as\}}} is called)
h4. Scenario 2.b.iii {{conf}} is writeable by nifi
see {{bootstrap.conf}} scenario explained above
h2. Conclusion
>From what I gather from the patches (I haven't built it as I am away from my
>dev box) we seem to be giving nifi ownership of most of the folders and
>assigning {{chmod 640}} on {{bin}}, {{conf}}, {{lib}} and pretty much
>everything else.
if that is the case we would be walking straight into the scenarios I listed
above and potentially others that we haven't foreseen.
Can someone confirm the permissions are similar to what [~jameswing] posted in
one of his previous
[comment|https://issues.apache.org/jira/browse/NIFI-1461?focusedCommentId=15135145&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15135145]
?
was (Author: trixpan):
[~joewitt]
May I suggest we hold this to 0.6.0 ?
I strongly suspect we may be moving too fast.
The main challenge we have is to run nifi.sh after installing from RPM. This is
what we must solve in this patch.
But we should do this without affecting the overall security of the resulting
system. So I took my dusted hat from the basement and tried to think from a
basic threat model perspective.
I can see a few basic issues we should try to avoid (this list is certainly not
extensive, just what come to my mind immediately).:
* *Scenario 1*: local unauthorised users (i.e. people outside the DFM role)
from tainting a NiFi setup.
* *Scenario 2*: remote users who can compromise nifi by an hypothetical
vulnerability from escalating privileges using the access to the NiFi user.
h2. Scenario 1
Possible approach
- No folder under the nifi install should be writeable by individuals other
than root or nifi (where applicable).
- It is imperative to note that write permissions should be granted only where
required by nifi. As an example, giving nifi write permissions to
{{conf/flow.xml.gz}} is required while giving write permissions to
{{conf/bootstrap.conf}} is not.
h2. Scenario 2:
This is a tricky one but I can try to address at least the cases I witnessed
during my pen-testing years (long long long time ago). I assume that an
hypothetical bug in nifi gave an unauthorised party access to the system shell
(under nifi UID and GID) and no config management/integrity check mechanism is
in use.
h3. Scenario 2.a - {{conf/bootstrap.conf}} is writeable by nifi
This is a particular case that I witness far too many time:
The intruder (but also the rogue DFM) modify {{run.as}} setting and wait for a
service restart as the desired user. Using a crafted script run through
*ExecuteScript* processor to obtain full root access.
h3. Scenario 2.b - Folders are writeable by nifi
One of my favourites.
Because of the way Unix filesystem permissions work, a user that has write
permission to directory is able to move files, even though sometimes it may be
unable to write the file itself.
Therefore the traditional to play around this situation is to move the target
file (i.e. rename {{bootstrap.conf}} ) and write a new one in its place and
then it is back to scenario 2.a
Attack would be like (where trixpan is the original {{run.as}} user)
{code}
$ ls -al
total 12
drwxr-xr-x 2 trixpan trixpan 4096 Feb 10 17:23 .
drwxr-xr-x 20 trixpan trixpan 4096 Feb 10 17:22 ..
-rw-r--r-- 1 root root 4 Feb 10 17:23 root_owns
$ echo bbb >> root_owns
-bash: root_owns: Permission denied
$ mv root_owns moved_root_owns
$ ls -al
total 12
drwxr-xr-x 2 trixpan trixpan 4096 Feb 10 17:23 .
drwxr-xr-x 20 trixpan trixpan 4096 Feb 10 17:23 ..
-rw-r--r-- 1 root root 4 Feb 10 17:23 moved_root_owns
$ cat moved_root_owns > root_owns
$ ls -al
total 16
drwxr-xr-x 2 trixpan trixpan 4096 Feb 10 17:26 .
drwxr-xr-x 20 trixpan trixpan 4096 Feb 10 17:23 ..
-rw-r--r-- 1 root root 4 Feb 10 17:23 moved_root_owns
-rw-r--r-- 1 trixpan trixpan 4 Feb 10 17:26 root_owns
{code}
h4. Scenario 2.b.i - {{lib}} is writeable by nifi
Intruder (or rogue DFM) replace a NAR file that can compromise the
confidentiality of the data flowing through NiFi (e.g. the PutS3 processor also
send data to intruder S3 buckets)
h4. Scenario 2.b.ii - {{bin}} is writeable by nifi
Intruder modifies {{nifi.sh}} to run whatever it wants whenever the service is
restarted (i.e. before {{sudo -u $\{run_as\}}} is called)
h4. Scenario 2.b.iii {{conf}} is writeable by nifi
see {{bootstrap.conf}} scenario explained above
h2. Conclusion
>From what I gather from the patches (I haven't built it as I am away from my
>dev box) we seem to be giving nifi ownership of most of the folders and
>assigning {{chmod 640}} on {{bin}}, {{conf}}, {{lib}} and pretty much
>everything else.
if that is the case we would be walking straight into the scenarios I listed
above and potentially others that we haven't foreseen.
Can someone confirm the permissions are similar to what [~jameswing] posted in
one of his previous
[comment|https://issues.apache.org/jira/browse/NIFI-1461?focusedCommentId=15135145&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15135145]
?
> RPM should create nifi user and give it access to the /opt/nifi and
> subdirectories
> ----------------------------------------------------------------------------------
>
> Key: NIFI-1461
> URL: https://issues.apache.org/jira/browse/NIFI-1461
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 0.4.1
> Reporter: Andre
> Assignee: Tony Kurc
> Labels: rpm
> Fix For: 0.5.0
>
> Attachments:
> 0001-NIFI-1461-This-closes-204.-Implemented-RPM-before-af.patch,
> 0002-NIFI-1461-added-run.as-filtered-property-for-RPM-and.patch, nifi.spec,
> nifi.spec
>
>
> currently when installing from RPM the resulting permissions result on admins
> having to complete the installation by adding a user and correcting
> filesystem permissions.
> Ideally the RPM packages should result in installed files ready to be
> utilised as a non-root user
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
