Currently the dcron-2.9.ebuild looks like this: exeopts -m 4750 -o root -g cron exeinto /usr/bin doexe crontab dodoc CHANGELOG README ${FILESDIR}/crontab doman crontab.1 crond.8 exeinto /etc/init.d ; newexe ${FILESDIR}/dcron.rc6 dcron ebuild to reflect these changes to prevent this from happening. exeopts -m 4750 -o root -g cron exeinto /usr/bin doexe crontab # exeopts -m 0755 -o root -g root dodoc CHANGELOG README ${FILESDIR}/crontab doman crontab.1 crond.8 exeinto /etc/init.d ; newexe ${FILESDIR}/dcron.rc6 dcron Reproducible: Didn't try Steps to Reproduce: This was an image we were preparing to netboot with and is an image was sync'd and built from stage1 lastnight. It is reproducable on this image. Actual Results: * >>> SetUID: [chmod go-r] /var/tmp/portage-pkg/dcron-2.9/bin/usr/bin/crontab * >>> SetUID: [chmod go-r] /var/tmp/portage-pkg/dcron-2.9/bin/etc/init.d/dcron It installed /etc/init.d/dcron suid -rws--x--- 1 root cron 632 Feb 25 18:06 /etc/init.d/dcron Expected Results: Installed the dcron init script with the following permissions. -rwxr-xr-x 1 root root 632 Nov 27 03:17 /etc/init.d/dcron Possibly numerous users have a suid dcron init script installed. Affected version from 2.7 -> 2.9-r1.
I've got an -r2 ready to go here. Just need the go ahead from a 3rd person.
go ahead
dcron-2.9-r2 commited to portage. Updated a few copyright from 2003-2004 KEYWORDS="~x86 ~amd64 ~ppc ~sparc ~hppa ~alpha ~mips" Please test, QA and mark it stable when ready. If it cant be marked stable then the ebuild update should be added to older versions.
Arches -- plztest and mark stable.
Marked stable on Alpha.
Stable on AMD64 (if only the permissions changed is there any real reason to test this on every architecture?)
stable on sparc.
stable on ppc
the reason I asked arches to test is because the previous version of the package was also ~masked on all arches.
Why is this a "Major" security assigned bug? scripts run using #! dont honour the suid bit. it's an error in the ebuild, but not a security bug..surely?
It's true that newer kernels don't carry the +s bit when executing most scripts however it's long known unix fact that a scripts should never be set{u,g}id in the first place. http://www.linux.com/howtos/Secure-Programs-HOWTO/shell.shtml http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html On Major vs Normal. I would think for sure it's not semi expected 'Normal' behavior to be giving +s bits away for free. It's risky behavior at best and this was clearly a boo boo in the ebuild on our part. Koon is helping sort out some documentation on Severity Levels/Classes for bugzilla bug handling and work flow of these types of bugs. If you would like to check it out and or offer suggestions mail him for a link. The following ebuilds should also be audited to ensure that they handle +s bits correctly after the exeopts() function is called. ./app-sci/chessbrain/chessbrain-20407.ebuild: exeopts "-m 4755 -o nobody -g nogroup" ./net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.0.1a-r1.ebuild: exeopts -m4711 ./net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.0.3b-r2.ebuild: exeopts -m4711 ./net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.0.3b-r3.ebuild: exeopts -m4711 ./net-print/pdq/pdq-2.2.1-r1.ebuild: exeopts -m 4755 -o root ./sys-apps/netkit-base/netkit-base-0.17-r6.ebuild: exeopts -m 4755 ./sys-apps/netkit-base/netkit-base-0.17-r7.ebuild: exeopts -m 4755 ./sys-apps/netkit-base/netkit-base-0.17-r8.ebuild: exeopts -m 4755
heino@heino heino $ epm -q -l pdq | xargs -n1 ls -ld -rwxr-xr-x 1 root root 1082 9. Apr 14:53 /etc/pdq/interfaces/local-port-1.0 -rwxr-xr-x 1 root root 1695 9. Apr 14:53 /etc/pdq/interfaces/tcp-port-2.0 -rwxr-xr-x 1 root root 1132 9. Apr 14:53 /etc/pdq/interfaces/efax-0.1 -rwxr-xr-x 1 root root 1869 9. Apr 14:53 /etc/pdq/interfaces/bsd-lpd-2.0 -rwxr-xr-x 1 root root 750 9. Apr 14:53 /etc/pdq/interfaces/appletalk-1.0 -rwxr-xr-x 1 root root 2893 9. Apr 14:53 /etc/pdq/drivers/misc/hp-laserjet-5-0.9 -rwxr-xr-x 1 root root 4392 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-bjc600-0.1 -rwxr-xr-x 1 root root 3048 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-cdj670-0.1 -rwxr-xr-x 1 root root 4454 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-bjc800-0.1 -rwxr-xr-x 1 root root 4210 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-stcolor-0.1 -rwxr-xr-x 1 root root 3060 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-cdj850-0.1 -rwxr-xr-x 1 root root 3043 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-cdj890-0.1 -rwxr-xr-x 1 root root 6805 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-uniprint-simple-0.1 -rwxr-xr-x 1 root root 3048 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-cdj1600-0.1 -rwxr-xr-x 1 root root 3786 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-declj250-0.1 -rwxr-xr-x 1 root root 5414 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-pjxl300-0.1 -rwxr-xr-x 1 root root 3786 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-pjtest-0.1 -rwxr-xr-x 1 root root 5387 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-pjxltest-0.1 -rwxr-xr-x 1 root root 4828 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-cdj500-0.1 -rwxr-xr-x 1 root root 4882 9. Apr 14:53 /etc/pdq/drivers/ghostscript/gs-cdj550-0.1 -rwxr-xr-x 1 root root 1273 9. Apr 14:53 /etc/pdq/drivers/generic/printcap-emulation-1.0 -rwxr-xr-x 1 root root 588 9. Apr 14:53 /etc/pdq/drivers/generic/generic-text-only-1.1 -rwxr-xr-x 1 root root 5645 9. Apr 14:53 /etc/pdq/drivers/generic/generic-postscript-1.2 -rwxr-xr-x 1 root root 2186 9. Apr 14:53 /etc/pdq/drivers/postscript/qms-magicolor-cx-1.1 -rwxr-xr-x 1 root root 7572 9. Apr 14:53 /etc/pdq/drivers/postscript/hp-2500-cm-2.0 -rwxr-xr-x 1 root root 7838 9. Apr 14:53 /etc/pdq/drivers/postscript/hp-4050-tn-1.0 -rwxr-xr-x 1 root root 1814 9. Apr 14:53 /etc/pdq/printrc.example -rw-r--r-- 1 root root 1814 9. Apr 14:53 /etc/pdq/printrc -rwxr-xr-x 1 root root 55772 9. Apr 14:53 /usr/bin/pdq -rwxr-xr-x 1 root root 108288 9. Apr 14:53 /usr/bin/xpdq -rwsr-xr-x 1 root root 10472 9. Apr 14:53 /usr/bin/lpd_cancel -rwsr-xr-x 1 root root 10268 9. Apr 14:53 /usr/bin/lpd_status -rwsr-xr-x 1 root root 13740 9. Apr 14:53 /usr/bin/lpd_print -rw-r--r-- 1 root root 772 9. Apr 14:53 /usr/share/doc/pdq-2.2.1-r1/CHANGELOG.gz -rw-r--r-- 1 root root 221 9. Apr 14:53 /usr/share/doc/pdq-2.2.1-r1/README.gz -rw-r--r-- 1 root root 6264 9. Apr 14:53 /usr/share/doc/pdq-2.2.1-r1/rfc1179.txt.gz -rw-r--r-- 1 root root 285 9. Apr 14:53 /usr/share/doc/pdq-2.2.1-r1/INSTALL.gz -rw-r--r-- 1 root root 6849 9. Apr 14:53 /usr/share/doc/pdq-2.2.1-r1/LICENSE.gz -rw-r--r-- 1 root root 3760 9. Apr 14:53 /usr/share/doc/pdq-2.2.1-r1/BUGS.gz -rw-r--r-- 1 root root 423 9. Apr 14:53 /usr/share/man/man1/pdqstat.1.gz -rw-r--r-- 1 root root 983 9. Apr 14:53 /usr/share/man/man1/lpd_print.1.gz -rw-r--r-- 1 root root 566 9. Apr 14:53 /usr/share/man/man1/lpd_status.1.gz -rw-r--r-- 1 root root 715 9. Apr 14:53 /usr/share/man/man1/lpd_cancel.1.gz -rw-r--r-- 1 root root 432 9. Apr 14:53 /usr/share/man/man1/xpdq.1.gz -rw-r--r-- 1 root root 919 9. Apr 14:53 /usr/share/man/man1/pdq.1.gz -rw-r--r-- 1 root root 3842 9. Apr 14:53 /usr/share/man/man5/printrc.5.gz I have to admit that i've never used pdq and that this is the first time i heard about it, the last change of the ebuild is on 1. Feb 2002 according to the changelog.
stable on hppa
x86: please test dcron-2.9-r2 and mark stable
Stable on x86
Thanks -- then it's ready for GLSA, or ready for closing. Do you think we need a GLSA on this one ?
I'd say this one probably doesn't need a glsa. the file was still only writable by root.
I'd also think this is not GLSA worthy however at the same time we probably should add some code to portage/baselayout/fixpackages or whatever that calls a chmod -s /etc/{init,conf}.d/*
OK, so let's close this one. Maybe someone should open another bug to have a chmod -s done by fixpackages or whatever. -K
