Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/1551
It is prudent to restrict the ACLs of the files and directories we ship
with to their most conservative level possible. I'll refer to these as 'SA'
(shipped artifacts) for my comments below.
It is also prudent to ensure we restrict the ACLs of the files and
directories our code creates to their most conservative level possible. I'll
refer to these as 'CA' (created artifacts) for my comments below.
We control the permissions of SA through our build process which
specifically is our maven assembly. Your PR shows we have a few areas to
tighten and we should. These include, for example, the base install directory,
the bin directory, the conf directory, NOTICE, LICENSE, etc..
We do not, until this PR, control the permissions of our CA through our
build process/maven assembly. Our CA items should be controlled by the code
creating these items in the most restrictive way possible and through honoring
operating system settings for things like umask, etc.. And we should have
clearly documented and allocated area(s) where CA items under default settings
would go in the event that they are actually invoked/created.
For cases where you'd like to make the base directory (an SA) more
restrictive than it can presently be due to common/default settings that result
in CA of things like flowfile/content/prov repositories then consider changing
the default storage location of those CAs to a specifically controlled
subdirectory like 'state' or something else. We can then document this 'state'
directory as the location accessible to the NiFi process to write to. Keeping
in mind of course that we have common practices today such as using conf
directory for things like the flow.xml.gz and a directory under it for backup
flows and so on. There are some things to think through there.
I think the mongodb lesson is important. We have to continually revisit
tradeoffs and decisions we've made regarding out of the box usability to
support onboarding new users and the effort required to have a secured system.
We need to continually make 'out of the box ease' and 'security' come closer
together. I think we're all in agreement there.
In summary, I'm supportive of us finding the most restrictive SA
configuration we can. I think we should adjust our code that generates CAs to
create things as restrictive as possible. I do think we should avoid
pre-generating CA artifacts.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
