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 _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
