compress old puppet reports

[seth vidal]

On Tue, 2011-05-17 at 18:59 +0200, Jan-Frode Myklebust wrote:
> On Tue, May 17, 2011 at 08:23:31AM -0400, seth vidal wrote:
> > >  
> > >  # clean up all but the last 1 month of puppet reports
> > > -/usr/sbin/tmpwatch --mtime 720 /var/lib/puppet/reports/
> > > +/sbin/runuser -s /bin/sh - puppet -c "/usr/sbin/tmpwatch --mtime 720 /var/lib/
> 
> (scary how git diff cuts lines at end of terminal..)

I suspect git did not - but I cut and pasted it badly.


> It guards against symlink attack by anyone who can run something as
> user "puppet" and replace /var/lib/puppet/reports/ with a symlink to
> somewhere else (/).

if they can run something as puppet then they can trivially get to root
since they could overwrite the puppet recipes and take over the machine
that way, can't they?



> > >  
> > >  for host in `echo /var/lib/puppet/reports/*`
> > >  do 
> > > - /bin/ls -1 $host/*.yaml | head --lines=-48 | xargs --no-run-if-empty xz -9
> > > + /bin/ls -1 $host/*.yaml | head --lines=-48 | \
> > > +       /sbin/runuser -s /bin/sh - puppet -c "xargs --no-run-if-empty xz -9"
> 
> Guards against races before xargs and bugs in xz which might be processesing
> client controlled input. Would it be conceivable that xz can create a
> compressed file that cron will interpret as a cronjob if placed in
> /etc/cron.d? Similar to https://lwn.net/Articles/191080/ ?

no. I don't think it is - not without a previous exploit on the machine
replacing xz.


> I don't know, but I couldn't rule it out -- so I would much rather run
> the maintenance scripts with the correct privileges instead of root.

if we're going on 'but couldn't rule it out' we may as well just halt
the whole thing.


> > I'm not sure how it makes a hill of beans worth of difference.
> > 
> > It makes no network connections and performs nothing controversial.
> 
> "puppetmaster" running as "puppet" listens on the network, and has access
> to change these paths. But I'll agree it's probably not a big
> difference since the impact is mostly destroying a machine -- not owning
> it.. Would be great if there were some easier way to specify which user
> each cron.daily job should run as.

puppetmaster listens on the network and only accepts connections from
hosts which are auth'd by an ssl certificate/key.

I don't mind running them as puppet - but I do think this is a
questionable security analysis.

-sv