[Bug 1158538] patch2mail: security hardening: run as unprivileged user
http://bugzilla.opensuse.org/show_bug.cgi?id=1158538
http://bugzilla.opensuse.org/show_bug.cgi?id=1158538#c3
Christian Boltz
Yes it looks good. But having to run zypper refresh as root reduces the value of this hardening quite a lot. I'm not sure if it is worth the added complexity in this case. What do you think?
It would be easy to run xsltproc as non-root, and looking at the amount of CVEs listed in libxslt-tools, that probably isn't the worst idea. That would mean (pseudo-patch) LANG=C /usr/bin/zypper --xmlout --non-interactive lu $params | \ + setpriv --reuid nobody \ xsltproc /usr/share/patch2mail/patch2mail.xsl - > "$tmp" This willl also need Requires: user(nobody) (I never used setpriv, does the syntax look correct?) The "mail" call could also run as non-root, but the security track of mailx looks much better than the one from xsltproc ;-) An alternative way could be to ship an AppArmor profile for patch2mail with Ux for zypper (because cachedir is configurable and could be != /var/cache/zypp) and ix for everything else, maybe even Cx to a restrictive child profile for xsltproc. With some additional effort (see my pseudocode), it would also be possible to run zypper lu and sourcing the sysconfig file as non-root, but...
One problem / possible regression I see is that errors in "zypper -q refresh" will not end up in the zypper lu output, and therefore won't be visible anymore.
It would not be part of the zypper lu output, but it should still be part of the cron output, no?
As we say in germany: "Jein" ;-) Currently refresh errors are part of the zypper xml output, and end up in the mail patch2mail will send out. If refreshing is done in a separate step, it will probably result in - a mail from cron showing stderr of the patch2mail cronjob ("refresh failed for $repo") - a mail from patch2mail showing available updates - without the warning about the refresh failure Merging both parts into one mail would make things more complicated again. IMHO sane options are a) only run xsltproc as nobody b) add an AppArmor profile Opinions? -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com