Date: Sat, 05 Oct 2013 14:06:18 -0700 From: Peter Wemm <peter@wemm.org> To: freebsd-arch@freebsd.org Subject: Re: Userland patch level Message-ID: <52507F4A.1050707@wemm.org> In-Reply-To: <8661tbsi40.fsf@nine.des.no> References: <8661tbsi40.fsf@nine.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6wF1E0jcQLWIM2mEI1s1qhekd1UIuAt92 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/5/13 11:11 AM, Dag-Erling Sm=F8rgrav wrote: > The attached patch adds a shell script, /libexec/freebsd-version, which= > has the current version patch level hardcoded and prints them when run.= > It can also be used to extract the version and patch level from the > installed kernel, even before rebooting after an upgrade. The goal is > to be able to correctly determine the userland version in situations > where it does not match what the running kernel reports, which is > commonly the case when using freebsd-update or when running inside a > jail. In the long run, this will make it possible for `pkg audit` and > similar tools to correctly report a vulnerable userland. IMHO, promoting the parsing strings like this is fraught with danger. Th= e canonical one-true-version is __FreeBSD_version, I'd much rather encourag= e people to refer to that, and it is available in newvers.sh in the same wa= y that you're building it now. We've been dealing with this problem at yahoo for several years now. Providing a convenient way to parse the __FreeBSD_version and kern.osreld= ate tags would be nice. Up until now, the most reliable way to determine the kernel and userland versions has been to parse kern.osreldate to find the running kernel, and= to parse /usr/include/osreldate.h to determine the userland version. buildworld itself even uses /usr/include/osreldate.h to reliably determin= e the userland version. I realize it's not quite as convenient to pull an osreldate out of a rand= om kernel file (vs the running one), but at least the running one is availab= le when the kernel itself isn't. What happens if you're in a chroot/jail where the kernel file itself isn't even present in the file system - eg: = was pxe booted? freebsd-version.sh.in seems fragile as presented. It's missing loader.conf.local parsing, hardcodes the assumption that you use /boot (v= s /efi), etc. The usage string has a -i option that doesn't seem to exist.= Secteam does bump the osreldate for patch releases, right? Woudn't that = be sufficient for userland audit tools to reliably identify vulnerable userl= ands? --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV --6wF1E0jcQLWIM2mEI1s1qhekd1UIuAt92 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJQf08ACgkQFRKuUnJ3cX99gACeK5OXs37JYvgZ3dsTPL2Q36u4 8zIAn0sEHR5oUGy1nik8Ty2TB92H4c+T =MLX1 -----END PGP SIGNATURE----- --6wF1E0jcQLWIM2mEI1s1qhekd1UIuAt92--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52507F4A.1050707>