Re: compress old puppet reports
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