Date: Wed, 27 May 2015 14:35:41 -0700 From: "Roger Marquis" <marquis@roble.com> To: "Mark Felder" <feld@FreeBSD.org> Cc: freebsd-ports@freebsd.org, freebsd-security@freebsd.org Subject: Re: New pkg audit / vuln.xml failures (php55, unzoo) In-Reply-To: <1432756690.2290224.279775121.3E052535@webmail.messagingengine.com> References: <alpine.BSF.2.11.1505171402430.52815@eboyr.pbz> <20150523153029.B7BD3280@hub.freebsd.org> <1432659389.3130746.278522905.6D1E6549@webmail.messagingengine.com> <cmu-lmtpd-575818-1432748437-6@sloti22t01> <1432756690.2290224.279775121.3E052535@webmail.messagingengine.com>
| previous in thread | raw e-mail | index | archive | help
>> * operators of FreeBSD servers (unlike Debian, Ubuntu, RedHat, Suse and >> OpenBSD server operators) have no assurance that their systems are >> secure. > > Slow down here for a second. Where's the command-line tool on RedHat or > Debian that lists only the known vulnerable packages? In RedHat you can create a security repo list ( grep "-security" /etc/apt/sources.list), install the security plugin (yum install yum-plugin-security) and 'yum check-update --security' for the same functionality as 'pkg audit -F'. Debian is even more obscure (apt-get upgrade -o Dir::Etc::SourceList=/etc/apt/security.sources.list --just-print). FreeBSD 'pkg audit' is much cleaner but what difference does that make, really, when you have a vulnerable package that isn't in the database? > But that's not the end of the story. That > command won't list vulnerabilities until they have a patch released. > Let's look at CVE-2015-0209 > https://access.redhat.com/security/cve/CVE-2015-0209 > Release date was March 23rd. No question there's variability in bugfix timeliness, especially for DOS-type bugs like CVE-2015-0209. FreeBSD ports maintainers are also able to commit patches and version updates much more quickly than their binary-only competitors, as noted with the php55/Makefile tweak. In the past that's what made FreeBSD a more secure OS to host applications on. But that's not the main issue this thread has been about. The issue that really matters from a security perspective is the completeness of the vulnerability database, vuln.xml in our case. > The grass is always greener... or is it? > > Let's just concentrate on how to improve things here and not worry about > how they're handling security issues because they have their own unique > problems to solve. I must say I am disappointed in the response to this serious and significant issue. My Redhat using co-workers, OTOH, are no doubt eating it up. Problem is I'm not the only one who has to defend their business unit's use of FreeBSD in a corporation that has otherwise nearly standardized on Redhat (and RH security, bash notwithstanding). Roger
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>