FS#55071 - [grafana] Insecure permissons on /var/lib/grafana

Attached to Project: Community Packages
Opened by Florian Pritz (bluewind) - Tuesday, 08 August 2017, 09:28 GMT
Last edited by Sébastien Luttringer (seblu) - Wednesday, 06 September 2017, 00:48 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
/var/lib/grafana/grafana.db is world readable by default and the parent directory is also accessible (755 in /usr/lib/tmpfiles.d/grafana.conf). The parent directory should only be readable by the grafana user itself (700).

The grafana db may contain login credentials for data sources.

Additional info:
* package version(s)
grafana 4.3.2-1

* config and/or log files etc.
Use the sqlite db (default)
This task depends upon

Closed by  Sébastien Luttringer (seblu)
Wednesday, 06 September 2017, 00:48 GMT
Reason for closing:  Fixed
Additional comments about closing:  grafana 4.4.3-1
Comment by Florian Pritz (bluewind) - Tuesday, 08 August 2017, 09:39 GMT
/etc/grafana.ini also has 644 permissions and may contain database passwords. I'd say that should also be 600.

Edit: Should be 600 instead of 700
Comment by Sébastien Luttringer (seblu) - Saturday, 12 August 2017, 00:59 GMT
I downgraded permissions for files managed by tmpfiles.d. User can edit, group can read basically.

About grafana.ini, switching it to 600 make the server unable to read its config.
So we need to move from dynamic user and group allocation to a static one to be able to set a file group in the package in order to let the server read the config.

My grafana config is without any password or secret like the default. Don't see the point to set it to 600 in my case.
As soon as someone put a secret in a config file in /etc, we may consider that it is his job to secure it.
On the other hand, there is plenty of potential secrets (db, smtp, github, etc), in this file and make it secure by default is maybe the wise direction.
Comment by Florian Pritz (bluewind) - Saturday, 12 August 2017, 10:01 GMT
Right, I've set my grafana config to 600 and changed the owner. I didn't actually check if you use a static or dynamic user before writing this. I guess it's up to you, but I think we should try to make the packages secure by default because I don't really expect users to check the file permissions.
Comment by Sébastien Luttringer (seblu) - Wednesday, 23 August 2017, 23:29 GMT
I reserved uid/gid 207 for grafana. This will require user intervention to chown all the files he uses. Arf.
Comment by Sébastien Luttringer (seblu) - Saturday, 26 August 2017, 20:49 GMT
Thinking again, this file is the only one who require a static uid. What do you think if we don't ship a default file and let users set it up?
Comment by Levente Polyak (anthraxx) - Sunday, 27 August 2017, 01:01 GMT
in my humble opinion it would be generally a better choice to have default secure file and choose to use static uid again. being secure by default makes sense and not ship such file just because of the sake to use non-static uid doesn't personally sound to me like a reasonable overall improvement in contrast to put users into the need to be aware of this and change rights accordingly (event if they should, that's not the point).
I had the exact same decision to make for kibana and i'm convinced it has far more value to be default secure for the cost of having a install file that creates a user compared to simple have 'fancy' dynamic user creation.

Loading...