Jira (PUP-10627) write public information to puppet_dir/public

67 views
Skip to first unread message

Mihai Buzgau (Jira)

unread,
Aug 19, 2020, 5:32:03 AM8/19/20
to puppe...@googlegroups.com
Mihai Buzgau created an issue
 
Puppet / Improvement PUP-10627
write public information to puppet_dir/public
Issue Type: Improvement Improvement
Assignee: Unassigned
Created: 2020/08/19 2:31 AM
Priority: Normal Normal
Reporter: Mihai Buzgau

[TODO]Add description

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Atlassian logo

Mihai Buzgau (Jira)

unread,
Aug 19, 2020, 5:32:03 AM8/19/20
to puppe...@googlegroups.com
Mihai Buzgau updated an issue
Change By: Mihai Buzgau
Labels: platform_7

Luchian Nemes (Jira)

unread,
Aug 19, 2020, 12:06:04 PM8/19/20
to puppe...@googlegroups.com
Luchian Nemes assigned an issue to Luchian Nemes
Change By: Luchian Nemes
Assignee: Luchian Nemes

Luchian Nemes (Jira)

unread,
Aug 20, 2020, 11:41:03 AM8/20/20
to puppe...@googlegroups.com
Luchian Nemes updated an issue
[TODO]Add description Puppet needs a new folder called `public` which should be accessible by everyone (public user class) and have the public puppet files such as reports (without sensitive data in them) stored there. Default location proposed is `/opt/puppetlabs/puppet/public` on Linux and `C:\ProgramData\PuppetLabs\puppet\public` on Microsoft Windows. Both the folder and containing files should have `0755` (rwxr-xr-x) permissions set. Installation/upgrade of puppet-agent should ensure the existence of this folder.

Custom path for this folder should be possible through custom settings in `puppet.conf` or using the `puppet config set publicdir <custom_path>` cli command. Current implementation should only include the `last_run_summary.yaml` file in said folder (which is currently located in `/opt/puppetlabs/puppet/cache/state` on Linux and `C:\ProgramData\PuppetLabs\puppet\cache\state` on Microsoft Windows).

Changes needed in Puppet Agent (regarding the new cli parameter setting and folder packaging) should be covered in PA-3253.

Mihai Buzgau (Jira)

unread,
Sep 2, 2020, 5:19:03 AM9/2/20
to puppe...@googlegroups.com
Mihai Buzgau updated an issue
Change By: Mihai Buzgau
Sprint: NW - 2020-09-01 , NW - 2020-09-16

Luchian Nemes (Jira)

unread,
Sep 2, 2020, 7:29:03 AM9/2/20
to puppe...@googlegroups.com
Luchian Nemes updated an issue
Change By: Luchian Nemes
Release Notes: Bug Fix
Release Notes Summary: A new folder named `public`, with 0755 access rights, has been added and is now the default location for the 'last_run_summary.yaml' report.

Trevor Vaughan (Jira)

unread,
Oct 27, 2020, 3:12:03 PM10/27/20
to puppe...@googlegroups.com
Trevor Vaughan commented on Improvement PUP-10627
 
Re: write public information to puppet_dir/public

What's the use case for this?

From what I'm seeing, it's a security violation based on pretty much any documentation that I can think of.

By default, even reports should not be accessible to all users. If you want to share this information, it should be isolated to a specific group and then users should be added to that group for access.

Josh Cooper (Jira)

unread,
Oct 27, 2020, 7:33:02 PM10/27/20
to puppe...@googlegroups.com

Josh Cooper (Jira)

unread,
Oct 27, 2020, 7:33:03 PM10/27/20
to puppe...@googlegroups.com
Josh Cooper updated an issue
 
Change By: Josh Cooper
Puppet needs a new folder called `public` which should be accessible by everyone (public user class) and have the public puppet files such as reports last run summary (without sensitive data in them) stored there. Default location proposed is `/opt/puppetlabs/puppet/public` on Linux and `C:\ProgramData\PuppetLabs\puppet\public` on Microsoft Windows. Both the folder and containing files should have `0755` (rwxr-xr-x) permissions set. Installation/upgrade of puppet-agent should ensure the existence of this folder.


Custom path for this folder should be possible through custom settings in `puppet.conf` or using the `puppet config set publicdir <custom_path>` cli command. Current implementation should only include the `last_run_summary.yaml` file in said folder (which is currently located in `/opt/puppetlabs/puppet/cache/state` on Linux and `C:\ProgramData\PuppetLabs\puppet\cache\state` on Microsoft Windows).

Changes needed in Puppet Agent (regarding the new cli parameter setting and folder packaging) should be covered in PA-3253.

Josh Cooper (Jira)

unread,
Oct 27, 2020, 7:33:03 PM10/27/20
to puppe...@googlegroups.com
Josh Cooper updated an issue
Change By: Josh Cooper
Fix Version/s: PUP 7.0.0

Josh Cooper (Jira)

unread,
Oct 27, 2020, 7:39:03 PM10/27/20
to puppe...@googlegroups.com
Josh Cooper commented on Improvement PUP-10627
 
Re: write public information to puppet_dir/public

The description was slightly misleading. Only the last_run_summary.yaml is written to the public directory, not reports or anything else from the state directory. The summary contains info such as:

 ---
 version:
 config: 1603825976
 puppet: 6.20.0
 resources:
 changed: 0
 corrective_change: 0
 failed: 0
 failed_to_restart: 0
 out_of_sync: 0
 restarted: 0
 scheduled: 0
 skipped: 0
 total: 7
 time:
 catalog_application: 0.010459000244736671
 config_retrieval: 0.1759160002693534
 convert_catalog: 0.021530000492930412
 fact_generation: 1.5078099993988872
 filebucket: 7.0e-05
 node_retrieval: 0.10805199947208166
 plugin_sync: 0.0966600002720952
 schedule: 0.000407
 startup_time: 0.395959
 total: 2.319386
 transaction_evaluation: 0.007814999669790268
 last_run: 1603825976
 changes:
 total: 0
 events:
 failure: 0
 success: 0
 total: 0

That said, we may want to set the default permissions of [\{{last_run_summary.yaml}} to \{{0640}}](https://github.com/puppetlabs/puppet/blob/06b7b17319da0906e77f3d2e3e40fe0ee2666337/lib/puppet/defaults.rb#L1772) and if folks want to make it visible to publicly, such as for monitoring, then they could specify the mode in puppet.conf:

 [main]
 last_run_summary = $publicdir/last_run_summary.yaml { mode = 0644 }

Thoughts?

Trevor Vaughan (Jira)

unread,
Oct 28, 2020, 7:53:03 AM10/28/20
to puppe...@googlegroups.com

Josh Cooper That information is sufficient to provide data as to how well automated/secured the system is over time (noop, etc...), what version (potentially exploitable) of puppet is being run, and the general load of the system.

None of this information should be exposed by default to anyone besides root. Start locked down and allow for loosening restrictions if at all possible.

To me, this information is like a system log. You don't expose your system logs to all users but you may allow some users, by group, to access certain logs for their job functions.

Luchian Nemes (Jira)

unread,
Nov 4, 2020, 5:37:03 AM11/4/20
to puppe...@googlegroups.com

Luchian Nemes (Jira)

unread,
Nov 4, 2020, 9:02:04 AM11/4/20
to puppe...@googlegroups.com
Luchian Nemes updated an issue
 
Change By: Luchian Nemes
Release Notes Summary: A new folder named `public`, with 0755 access rights, has been added and is now the default location for the 'last_run_summary.yaml' report which now has `640` file permissions .

Josh Cooper (Jira)

unread,
Nov 4, 2020, 12:25:03 PM11/4/20
to puppe...@googlegroups.com

Claire Cadman (Jira)

unread,
Nov 9, 2020, 11:44:03 AM11/9/20
to puppe...@googlegroups.com
Claire Cadman updated an issue
 
Change By: Claire Cadman
Labels: doc_reviewed platform_7

R.I.Pienaar (Jira)

unread,
May 13, 2021, 6:22:04 AM5/13/21
to puppe...@googlegroups.com
R.I.Pienaar commented on Improvement PUP-10627
 
Re: write public information to puppet_dir/public

Came across this since the initial request that put the file here was PA-3253 and that created the "public" directory, now we have 0640 files in a public directory, which doesnt seem like the right thing to do and again makes it so that monitoring the puppet system can only be done as root?

This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
Atlassian logo

Scott Cyprus (Jira)

unread,
May 14, 2021, 4:33:04 PM5/14/21
to puppe...@googlegroups.com
Scott Cyprus commented on Improvement PUP-10627

It's very concerning that this "improvement" request was implemented without a second thought. 755 and 644 on a file that could get someone hacked? People are trusting your software to run on their systems, and careless changes like this erode that trust really quickly. It wasn't a "great catch" by Trevor, it was common sense. 

Please keep in mind that people use puppet to install software, and that software has an attack surface. If a hacker gains a limited shell on the machine and sees that puppet is running an outdated and vulnerable version then that is an easy way in.

Scott Cyprus (Jira)

unread,
May 14, 2021, 4:35:02 PM5/14/21
to puppe...@googlegroups.com
Scott Cyprus commented on Improvement PUP-10627

It's very concerning that this "improvement" request was implemented without a second thought. 755 and 644 on a file that could get someone hacked? People are trusting your software to run on their systems, and careless changes like this erode that trust really quickly. It wasn't a "great catch" by Trevor, it was common sense. 

Please keep in mind that people use puppet to install software, and that software has an attack surface. If a hacker gains a limited shell on the machine and sees that puppet is running an outdated and vulnerable version then that is an easy way to escalate privileges.

Scott Cyprus (Jira)

unread,
May 14, 2021, 4:35:03 PM5/14/21
to puppe...@googlegroups.com
Scott Cyprus updated an issue
 
Change By: Scott Cyprus
Comment:
It's very concerning that this "improvement" request was implemented without a second thought. 755 and 644 on a file that could get someone hacked? People are trusting your software to run on their systems, and careless changes like this erode that trust really quickly. It wasn't a "great catch" by Trevor, it was common sense. 

Please keep in mind that people use puppet to install software, and that software has an attack surface. If a hacker gains a limited shell on the machine and sees that puppet is running an outdated and vulnerable version then that is an easy way to escalate privileges.

R.I.Pienaar (Jira)

unread,
May 14, 2021, 4:55:01 PM5/14/21
to puppe...@googlegroups.com
R.I.Pienaar commented on Improvement PUP-10627
 
Re: write public information to puppet_dir/public

The file was not executable.

It doesn’t indicate what the load of the system is and there are far simpler ways to determine what version of puppet is being run.

It holds SIGNIFICANTLY less information than a report - as a response to “by default even reports should be accessible”. You are right which is why they are not. This summary file is not nearly as big a deal as suggested here. And those who are in highly controlled environments are used to tightening things down. This file has a very useful utility - and that is so that monitoring tools monitoring the health of puppet does not need to be run as root.

Josh Cooper (Jira)

unread,
May 14, 2021, 7:23:02 PM5/14/21
to puppe...@googlegroups.com
Josh Cooper commented on Improvement PUP-10627

R.I.Pienaar I think you meant "by default even reports should NOT be accessible?

Scott Cyprus The reason for the path change is because the old parent directory /opt/puppetlabs/puppet/cache is not read/executable by other. So in order to make the last_run_summary.yaml readable by monitoring software, you'd have to relax the permissions on the parent cache as well. But that directory can contain sensitive information last_run_report.yaml, so a bigger change was required.

The new public directory is read/executable by other, but the last_run_summary.yaml file is not readable, because we are following secure by default practices. If you are an advanced user and want to allow a specific user/group access to the summary file, then it's up to you.

I understand the concern around the version number and correlating that with known exploits, but the version number is not a secret. It's literally one command away:

$ cat /opt/puppetlabs/puppet/VERSION
7.6.1

and there are about 6 other ways to get the same information.

Also know that this feature wasn't "implemented without a second thought." We actually did put a lot of thought into this, but sometimes oversights happen, and we welcome feedback.

Scott Cyprus (Jira)

unread,
May 14, 2021, 7:56:02 PM5/14/21
to puppe...@googlegroups.com
Scott Cyprus commented on Improvement PUP-10627

Josh Cooper Thanks for the quick response. I did see that the original 644 change was caught and changed to 640, which is fine. I was more concerned about the original 644 permission. Fair point about the version being accessible elsewhere, although some of the other info in the file such as failed runs and last_run is a bit sensitive as well. Honestly, I was less concerned about the somewhat-sensitive information in the file, and more concerned with the permissions that the file was given. It's just a bad look, you know? It made me wonder, "What else on my system has similar permissions that I didn't happen to read about in the change logs?"

R.I.Pienaar (Jira)

unread,
May 15, 2021, 12:55:03 AM5/15/21
to puppe...@googlegroups.com
R.I.Pienaar commented on Improvement PUP-10627

Yeah, sorry I copied down from Trevor incorrectly, indeed reports should be not be accessible as they hold vast troves of information

The whole reason this public directory was even made was due to the request - by many people over the years - to restore last run summary to world readable as it was in the distant past. It was great to see that was done as it solved a security issue for many enabling monitoring as non root. The ability to control file modes in config files is known by very few people ime based on chat history etc

now we are back where we started - hard to use defaults for the majority average users. And more confusingly a public directory that holds a non public file 

Scott Cyprus (Jira)

unread,
May 17, 2021, 9:25:05 AM5/17/21
to puppe...@googlegroups.com
Scott Cyprus commented on Improvement PUP-10627

R.I.Pienaar > The ability to control file modes in config files is known by very few people ime based on chat history etc

I hate to sound like an elitist jerk, but why should other people's ignorance dictate how a product is secured by default? It begs the question, how far are we willing to go to accomodate the weakest link? If someone doesn't understand how groups work, then in my opinion they shouldn't be anywhere near puppet code that will presumably be run on many systems.

R.I.Pienaar (Jira)

unread,
May 18, 2021, 3:59:02 AM5/18/21
to puppe...@googlegroups.com
R.I.Pienaar commented on Improvement PUP-10627

The product is secure, the information in this file is not a security risk for the vast number of users.  Those who function in repressive security environments can carry the cost associated with learning every minute detail and tweaking it all to their exact needs - as they already do for everything they use.  Leaving sane defaults for the majority of users.

 

Thats why this directory was made to specifically make it easy and obvious where and what puppet is providing as public - the problem is a) a file in there is not public b) it's not public because 1 user decided its a risk while 10s felt its good use to make that data public.

When picking defaults its common for those to be picked in a way to serve the majority and then allow the minorities who do need things at a much more restrictive level to adjust things.

Catering to new users with sane defaults the promote a safe use of the product is not their "ignorance", it's just how new users are and how people who do not make a product their entire life exist. It's a careful balance in product design. Another tenet of product design is that of consistency and obviousness and now we have a non public file in a public directory which is not consistent or obvious.

And yes, every response by you so far has been that of a Jerk Scott Cyprus I'd appreciate if you can town it down a bit to a more civil level. It would also help if you didnt edit out entire comments so that when people respond to you others can see what the responses are about.

 

Damon Maria (Jira)

unread,
Aug 9, 2021, 3:01:04 AM8/9/21
to puppe...@googlegroups.com
Damon Maria commented on Improvement PUP-10627

I have tried to make the last_run_summary.yaml public by adding the following to puppet.conf (as per the 7.0.0 release notes):

[agent]
lastrunsummary = $publicdir/last_run_summary.yaml { owner = root, group = root, mode = 0644 }

 

But it makes no difference. I have restarted the agent and replaced $publicdir with the actual value but nothing changes about the file when the agent runs. What am I doing wrong?

Luchian Nemes (Jira)

unread,
Aug 9, 2021, 4:17:04 AM8/9/21
to puppe...@googlegroups.com

Damon Maria. a bit confusing, I know, but it's actually called lastrunfile. Running puppet config print shows all the available settings.

Damon Maria (Jira)

unread,
Aug 9, 2021, 2:42:02 PM8/9/21
to puppe...@googlegroups.com
Damon Maria commented on Improvement PUP-10627

Thanks Luchian Nemes. Explains why I couldn't find the lastrunsummary setting mentioned in the release notes.

Also, the docs you linked to have a mistake I think. For lastrunfile it says the default is in $statedir, I think that should be $publicdir.

Reply all
Reply to author
Forward
0 new messages