Add a chapter covering some issues at the intersection of the topics
of the ports collection and security, i.e., handling security vulnerabilities in ports, the VuXML database, etc. PR: docs/68605 Collaborated with: eik
This commit is contained in:
Yaroslav Tykhiy
parent
cbbe553f53
commit
f282cd9175
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=21691
2 changed files with 530 additions and 1 deletions
|
|
@ -25,5 +25,17 @@ SRCS= book.sgml
|
||||||
DSLHTML?= ${.CURDIR}/freebsd.dsl
|
DSLHTML?= ${.CURDIR}/freebsd.dsl
|
||||||
DSLPRINT?= ${.CURDIR}/freebsd.dsl
|
DSLPRINT?= ${.CURDIR}/freebsd.dsl
|
||||||
|
|
||||||
|
# Images from the cross-document image library
|
||||||
|
IMAGES_LIB+= callouts/1.png
|
||||||
|
IMAGES_LIB+= callouts/2.png
|
||||||
|
IMAGES_LIB+= callouts/3.png
|
||||||
|
IMAGES_LIB+= callouts/4.png
|
||||||
|
IMAGES_LIB+= callouts/5.png
|
||||||
|
IMAGES_LIB+= callouts/6.png
|
||||||
|
IMAGES_LIB+= callouts/7.png
|
||||||
|
IMAGES_LIB+= callouts/8.png
|
||||||
|
IMAGES_LIB+= callouts/9.png
|
||||||
|
IMAGES_LIB+= callouts/10.png
|
||||||
|
|
||||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||||
|
|
|
||||||
|
|
@ -769,7 +769,7 @@ PLIST_DIRS= lib/X11/oneko</programlisting>
|
||||||
to the version number of the port.</para>
|
to the version number of the port.</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2>
|
<sect2 id="makefile-naming-revepoch">
|
||||||
<title><makevar>PORTREVISION</makevar> and
|
<title><makevar>PORTREVISION</makevar> and
|
||||||
<makevar>PORTEPOCH</makevar></title>
|
<makevar>PORTEPOCH</makevar></title>
|
||||||
|
|
||||||
|
|
@ -5440,6 +5440,523 @@ IGNORE=POINTYHAT is not supported
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
|
<chapter id="security">
|
||||||
|
<title>Ports security</title>
|
||||||
|
|
||||||
|
<sect1 id="security-intro">
|
||||||
|
<title>Why security is so important</title>
|
||||||
|
|
||||||
|
<para>Bugs are occasionally introduced to the software.
|
||||||
|
Arguably, the most dangerous of them are those opening
|
||||||
|
security vulnerabilities. From the technical viewpoint,
|
||||||
|
such vulnerabilities are to be closed by exterminating
|
||||||
|
the bugs that caused them. However, the policies for
|
||||||
|
handling mere bugs and security vulnerabilities are
|
||||||
|
very different.</para>
|
||||||
|
|
||||||
|
<para>A typical small bug affects only those users who have
|
||||||
|
enabled some combination of options triggering the bug.
|
||||||
|
The developer will eventually release a patch followed
|
||||||
|
by a new version of the software, free of the bug, but
|
||||||
|
the majority of users will not take the trouble of upgrading
|
||||||
|
immediately because the bug has never vexed them. A
|
||||||
|
critical bug that may cause data loss represents a graver
|
||||||
|
issue. Nevertheless, prudent users know that a lot of
|
||||||
|
possible accidents, besides software bugs, are likely to
|
||||||
|
lead to data loss, and so they make backups of important
|
||||||
|
data; in addition, a critical bug will be discovered
|
||||||
|
really soon.</para>
|
||||||
|
|
||||||
|
<para>A security vulnerability is all different. First,
|
||||||
|
it may remain unnoticed for years because often it does
|
||||||
|
not cause software malfunction. Second, a malicious party
|
||||||
|
can use it to gain unauthorized access to a vulnerable
|
||||||
|
system, to destroy or alter sensitive data; and in the
|
||||||
|
worst case the user will not even notice the harm caused.
|
||||||
|
Third, exposing a vulnerable system often assists attackers
|
||||||
|
to break into other systems that could not be compromised
|
||||||
|
otherwise. Therefore closing a vulnerability alone is
|
||||||
|
not enough: the audience should be notified of it in most
|
||||||
|
clear and comprehensive manner, which will allow to
|
||||||
|
evaluate the danger and take appropriate actions.</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
<sect1 id="security-fix">
|
||||||
|
<title>Fixing security vulnerabilities</title>
|
||||||
|
|
||||||
|
<para>While on the subject of ports and packages, a security
|
||||||
|
vulnerability may initially appear in the original
|
||||||
|
distribution or in the port files. In the former case,
|
||||||
|
the original software developer is likely to release a
|
||||||
|
patch or a new version instantly, and you will
|
||||||
|
only need to update the port promptly with respect to
|
||||||
|
the author's fix. If the fix is delayed for some reason,
|
||||||
|
you should either <link linkend="dads-broken">mark the port as
|
||||||
|
<makevar>FORBIDDEN</makevar></link>
|
||||||
|
or introduce a patch file of your own to the port. In
|
||||||
|
the case of a vulnerable port, just fix the port as soon as
|
||||||
|
possible. In either case, <link linkend="port-upgrading">the
|
||||||
|
standard procedure for submitting your change</link> should
|
||||||
|
be followed unless you have rights to commit it directly
|
||||||
|
to the ports tree.</para>
|
||||||
|
|
||||||
|
<important>
|
||||||
|
<para>Being a ports committer is not enough to commit to
|
||||||
|
an arbitrary port. Remember that ports usually have
|
||||||
|
maintainers, whom you should respect.</para>
|
||||||
|
</important>
|
||||||
|
|
||||||
|
<para>Please make sure that the port's revision is bumped
|
||||||
|
as soon as the vulnerability has been closed.
|
||||||
|
That is how the users who upgrade installed packages
|
||||||
|
on a regular basis will see they need to run an update.
|
||||||
|
Besides, a new package will be built and distributed
|
||||||
|
over FTP and WWW mirrors, replacing the vulnerable one.
|
||||||
|
<makevar>PORTREVISION</makevar> should be bumped unless
|
||||||
|
<makevar>PORTVERSION</makevar> has changed in the course
|
||||||
|
of correcting the vulnerability. That is you should
|
||||||
|
bump <makevar>PORTREVISION</makevar> if you have added a
|
||||||
|
patch file to the port, but you should not if you have updated
|
||||||
|
the port to the latest software version and thus already
|
||||||
|
touched <makevar>PORTVERSION</makevar>. Please refer to the
|
||||||
|
<link linkend="makefile-naming-revepoch">corresponding section</link>
|
||||||
|
for more information.</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
<sect1 id="security-notify">
|
||||||
|
<title>Keeping the community informed</title>
|
||||||
|
|
||||||
|
<sect2 id="security-notify-vuxml-db">
|
||||||
|
<title>The VuXML database</title>
|
||||||
|
|
||||||
|
<para>A very important and urgent step to take as early as
|
||||||
|
a security vulnerability is discovered is to notify the
|
||||||
|
community of port users about the jeopardy. Such
|
||||||
|
notification serves two purposes. First, should the danger
|
||||||
|
be really severe, it will be wise to apply an instant workaround,
|
||||||
|
e.g., stop the affected network service or even deinstall
|
||||||
|
the port completely, until the vulnerability is closed.
|
||||||
|
Second, a lot of users tend to upgrade installed packages
|
||||||
|
just occasionally. They will know from the notification
|
||||||
|
that they <emphasis>must</emphasis> update the package
|
||||||
|
without delay as soon as a corrected version is available.
|
||||||
|
|
||||||
|
<para>Given the huge number of ports in the tree,
|
||||||
|
a security advisory cannot be issued on each incident
|
||||||
|
without creating a flood and losing the attention of
|
||||||
|
the audience by the time it comes to really serious
|
||||||
|
matters. Therefore security vulnerabilities found in
|
||||||
|
ports are recorded in <ulink
|
||||||
|
url="http://vuxml.freebsd.org/">the FreeBSD VuXML
|
||||||
|
database</ulink>. The Security Officer Team members
|
||||||
|
are monitoring it for issues requiring their
|
||||||
|
intervention.</para>
|
||||||
|
|
||||||
|
<para>If you have committer rights, you can update the VuXML
|
||||||
|
database by yourself. So you will both help the Security
|
||||||
|
Officer Team and deliver the crucial information to the
|
||||||
|
community earlier. However, if you are not a committer,
|
||||||
|
or you believe you have found an exceptionally severe
|
||||||
|
vulnerability, or whatever, please do not hesitate to
|
||||||
|
contact the Security Officer Team directly as described
|
||||||
|
on the <ulink
|
||||||
|
url="http://www.freebsd.org/security/#how">FreeBSD
|
||||||
|
Security Information</ulink> page.</para>
|
||||||
|
|
||||||
|
<para>All right, you elected the hard way. As it may be obvious
|
||||||
|
from its title, the VuXML database is essentially an
|
||||||
|
XML document. Its source file <filename>vuln.xml</filename>
|
||||||
|
is kept right inside the port <filename
|
||||||
|
role="package">security/vuxml</filename>. Therefore
|
||||||
|
the file's full pathname will be
|
||||||
|
<filename><envar>PORTSDIR</envar>/security/vuxml/vuln.xml</filename>.
|
||||||
|
Each time you discover a security vulnerability in a
|
||||||
|
port, please add an entry for it to that file.
|
||||||
|
Until you are familiar with VuXML, the best thing you can
|
||||||
|
do is to find an existing entry fitting your case, then copy
|
||||||
|
it and use as a template.</para>
|
||||||
|
</sect2>
|
||||||
|
|
||||||
|
<sect2 id="security-notify-vuxml-intro">
|
||||||
|
<title>A short introduction to VuXML</title>
|
||||||
|
|
||||||
|
<para>The full-blown XML is complex and far beyond the scope of
|
||||||
|
this book. However, to gain basic insight on the structure
|
||||||
|
of a VuXML entry, you need only the notion of tags. XML
|
||||||
|
tag names are enclosed in angle brackets. Each opening
|
||||||
|
<tag> must have a matching closing </tag>.
|
||||||
|
Tags may be nested. If nesting, the inner tags must be
|
||||||
|
closed before the outer ones. There is a hierarchy of
|
||||||
|
tags, i.e. more complex rules of nesting them. Sounds
|
||||||
|
very similar to HTML, doesn't it? The major difference
|
||||||
|
is that XML is e<emphasis>X</emphasis>tensible, i.e. based
|
||||||
|
on defining custom tags. Due to its intrinsic structure,
|
||||||
|
XML puts otherwise amorphous data into shape. VuXML is
|
||||||
|
particularly tailored to mark up descriptions of security
|
||||||
|
vulnerabilities.</para>
|
||||||
|
|
||||||
|
<para>Now let's consider a realistic VuXML entry:</para>
|
||||||
|
|
||||||
|
<programlisting><vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> <co id="co-vx-vid">
|
||||||
|
<topic>Several vulnerabilities found in Foo</topic> <co id="co-vx-top">
|
||||||
|
<affects>
|
||||||
|
<package>
|
||||||
|
<name>foo</name> <co id="co-vx-nam">
|
||||||
|
<name>foo-devel</name>
|
||||||
|
<name>ja-foo</name>
|
||||||
|
<range><ge>1.6</ge><lt>1.9</lt></range> <co id="co-vx-rng">
|
||||||
|
<range><ge>2.*</ge><lt>2.4_1</lt></range>
|
||||||
|
<range><eq>3.0b1</eq></range>
|
||||||
|
</package>
|
||||||
|
<package>
|
||||||
|
<name>openfoo</name> <co id="co-vx-nm2">
|
||||||
|
<range><lt>1.10_7</lt></range> <co id="co-vx-epo">
|
||||||
|
<range><ge>1.2,1</ge><lt>1.3_1,1</lt></range>
|
||||||
|
</package>
|
||||||
|
</affects>
|
||||||
|
<description>
|
||||||
|
<body xmlns="http://www.w3.org/1999/xhtml">
|
||||||
|
<p>J. Random Hacker reports:</p> <co id="co-vx-bdy">
|
||||||
|
<blockquote
|
||||||
|
cite="http://j.r.hacker.com/advisories/1">
|
||||||
|
<p>Several issues in the Foo software may be exploited
|
||||||
|
via carefully crafted QUUX requests. These requests will
|
||||||
|
permit the injection of Bar code, mumble theft, and the
|
||||||
|
readability of the Foo administrator account.</p>
|
||||||
|
</blockquote>
|
||||||
|
</body>
|
||||||
|
</description>
|
||||||
|
<references> <co id="co-vx-ref">
|
||||||
|
<freebsdsa>SA-10:75.foo</freebsdsa> <co id="co-vx-fsa">
|
||||||
|
<freebsdpr>ports/987654</freebsdpr> <co id="co-vx-fpr">
|
||||||
|
<cvename>CAN-2010-0201</cvename> <co id="co-vx-cve">
|
||||||
|
<cvename>CAN-2010-0466</cvename>
|
||||||
|
<bid>96298</bid> <co id="co-vx-bid">
|
||||||
|
<certsa>CA-2010-99</certsa> <co id="co-vx-cts">
|
||||||
|
<certvu>740169</certvu> <co id="co-vx-ctv">
|
||||||
|
<uscertsa>SA10-99A</uscertsa> <co id="co-vx-ucs">
|
||||||
|
<uscertta>SA10-99A</uscertta> <co id="co-vx-uct">
|
||||||
|
<mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> <co id="co-vx-mls">
|
||||||
|
<url>http://j.r.hacker.com/advisories/1</url> <co id="co-vx-url">
|
||||||
|
</references>
|
||||||
|
<dates>
|
||||||
|
<discovery>2010-05-25</discovery> <co id="co-vx-dsc">
|
||||||
|
<entry>2010-07-13</entry> <co id="co-vx-ent">
|
||||||
|
<modified>2010-09-17</entry> <co id="co-vx-mod">
|
||||||
|
</dates>
|
||||||
|
</vuln></programlisting>
|
||||||
|
|
||||||
|
<para>The tag names are supposed to be self-descriptive,
|
||||||
|
so we shall take a closer look only at fields you will need
|
||||||
|
to fill in by yourself:</para>
|
||||||
|
|
||||||
|
<calloutlist>
|
||||||
|
<callout arearefs="co-vx-vid">
|
||||||
|
<para>This is the top-level tag of a VuXML entry. It has
|
||||||
|
a mandatory attribute, <literal>vid</literal>,
|
||||||
|
specifying a universally unique identifier (UUID) for
|
||||||
|
this entry (in quotes). You should generate a UUID
|
||||||
|
for each new VuXML entry (and don't forget to substitute
|
||||||
|
it for the template UUID unless you are writing the
|
||||||
|
entry from scratch). You can use &man.uuidgen.1; in
|
||||||
|
FreeBSD 5.x, or you may install the port <filename
|
||||||
|
role="package">devel/p5-Data-UUID</filename> and issue
|
||||||
|
the following command:</para>
|
||||||
|
|
||||||
|
<programlisting>perl -MData::UUID -le 'print lc new Data::UUID->create_str'</programlisting>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-top">
|
||||||
|
<para>This is a one-line description of the issue found.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-nam">
|
||||||
|
<para>The names of packages affected are listed there.
|
||||||
|
Multiple names can be given since several packages may be
|
||||||
|
based on a single master port or software product. This
|
||||||
|
may include stable and development branches, localized
|
||||||
|
versions, and slave ports featuring different choices of
|
||||||
|
important build-time configuration options.</para>
|
||||||
|
|
||||||
|
<important>
|
||||||
|
<para>It is your resposibility to find all such related
|
||||||
|
packages when writing a VuXML entry. Keep in mind that
|
||||||
|
<literal>make search name=foo</literal> is your friend.
|
||||||
|
The primary points to look for are as follows:</para>
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>the <filename>foo-devel</filename> variant
|
||||||
|
for a <filename>foo</filename> port;</para>
|
||||||
|
</listitem>
|
||||||
|
|
||||||
|
<listitem>
|
||||||
|
<para>other variants with a suffix like
|
||||||
|
<literal>-a4</literal> (for print-related packages),
|
||||||
|
<literal>-without-gui</literal> (for packages with X
|
||||||
|
support disabled), or similar;</para>
|
||||||
|
</listitem>
|
||||||
|
|
||||||
|
<listitem>
|
||||||
|
<para><literal>jp-</literal>, <literal>ru-</literal>,
|
||||||
|
<literal>zh-</literal>, and other possible localized
|
||||||
|
variants in the corresponding national categories of
|
||||||
|
the ports collection.</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</important>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-rng">
|
||||||
|
<para>Affected versions of the package(s) are specified
|
||||||
|
there as one or more ranges using a combination of
|
||||||
|
<literal><lt></literal>, <literal><le></literal>,
|
||||||
|
<literal><eq></literal>, <literal><ge></literal>,
|
||||||
|
and <literal><gt></literal> elements. The
|
||||||
|
version ranges given should not overlap.</para>
|
||||||
|
|
||||||
|
<para>In a range specification, <literal>*</literal> (asterisk)
|
||||||
|
denotes the smallest version number. In particular,
|
||||||
|
<literal>2.*</literal> is less than <literal>2.a</literal>.
|
||||||
|
Therefore an asterisk may be used for a range to match all
|
||||||
|
possible <literal>alpha</literal>, <literal>beta</literal>,
|
||||||
|
and <literal>RC</literal> versions. For instance,
|
||||||
|
<literal><ge>2.*</ge><lt>3.*</lt></literal>
|
||||||
|
will selectively match every <literal>2.x</literal> version while
|
||||||
|
<literal><ge>2.0</ge><lt>3.0</lt></literal>
|
||||||
|
will obviously not since the latter misses
|
||||||
|
<literal>2.r3</literal> and matches
|
||||||
|
<literal>3.b</literal>.</para>
|
||||||
|
|
||||||
|
<para>The above example
|
||||||
|
specifies that affected are versions from <literal>1.6</literal>
|
||||||
|
to <literal>1.9</literal> inclusive, versions
|
||||||
|
<literal>2.x</literal> before <literal>2.4_1</literal>,
|
||||||
|
and version <literal>3.0b1</literal>.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-nm2">
|
||||||
|
<para>Several related package groups (essentially, ports)
|
||||||
|
can be listed in the <literal><affected></literal>
|
||||||
|
section. This can be used if several software products
|
||||||
|
(say FooBar, FreeBar and OpenBar) grow from the same code base
|
||||||
|
and still share its bugs and vulnerabilities. Note the
|
||||||
|
difference from listing multiple names within a single
|
||||||
|
<package> section.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-epo">
|
||||||
|
<para>The version ranges should allow for
|
||||||
|
<makevar>PORTEPOCH</makevar> and
|
||||||
|
<makevar>PORTREVISION</makevar> if applicable.
|
||||||
|
Please remember that according to the collation rules,
|
||||||
|
a version with a non-zero <makevar>PORTEPOCH</makevar> is
|
||||||
|
greater than any version without
|
||||||
|
<makevar>PORTEPOCH</makevar>, e.g., <literal>3.0,1</literal>
|
||||||
|
is greater than <literal>3.1</literal> or even than
|
||||||
|
<literal>8.9</literal>.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-bdy">
|
||||||
|
<para>This is a summary of the issue.
|
||||||
|
XHTML is used in this field. At least enclosing
|
||||||
|
<literal><p></literal> and <literal></p></literal>
|
||||||
|
should appear. More complex mark-up may be used, but only for
|
||||||
|
the sake of accuracy and clarity: No eye candy please.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-ref">
|
||||||
|
<para>This section contains references to relevant documents.
|
||||||
|
As many references as apply are encouraged.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-fsa">
|
||||||
|
<para>This is a
|
||||||
|
<ulink url="http://www.freebsd.org/security/#adv">FreeBSD
|
||||||
|
security advisory</ulink>.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-fpr">
|
||||||
|
<para>This is a
|
||||||
|
<ulink url="http://www.freebsd.org/support.html#gnats">FreeBSD
|
||||||
|
problem report</ulink>.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-cve">
|
||||||
|
<para>This is a <ulink url="http://www.cve.mitre.org/">Mitre
|
||||||
|
CVE</ulink> identifier.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-bid">
|
||||||
|
<para>This is a
|
||||||
|
<ulink url="http://www.securityfocus.com/bid">SecurityFocus
|
||||||
|
Bug ID</ulink>.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-cts">
|
||||||
|
<para>This is a
|
||||||
|
<ulink url="http://www.cert.org/">US-CERT</ulink>
|
||||||
|
security advisory.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-ctv">
|
||||||
|
<para>This is a
|
||||||
|
<ulink url="http://www.cert.org/">US-CERT</ulink>
|
||||||
|
vulnerability note.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-ucs">
|
||||||
|
<para>This is a
|
||||||
|
<ulink url="http://www.cert.org/">US-CERT</ulink>
|
||||||
|
Cyber Security Alert.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-uct">
|
||||||
|
<para>This is a
|
||||||
|
<ulink url="http://www.cert.org/">US-CERT</ulink>
|
||||||
|
Technical Cyber Security Alert.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-mls">
|
||||||
|
<para>This is a URL to an archived posting in a mailing list.
|
||||||
|
The attribute <literal>msgid</literal> is optional and
|
||||||
|
may specify the message ID of the posting.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-url">
|
||||||
|
<para>This is a generic URL. It should be used only if none of
|
||||||
|
the other reference categories apply.</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-dsc">
|
||||||
|
<para>This is the date when the issue was disclosed
|
||||||
|
(<replaceable>YYYY-MM-DD</replaceable>).</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-ent">
|
||||||
|
<para>This is the date when the entry was added
|
||||||
|
(<replaceable>YYYY-MM-DD</replaceable>).</para>
|
||||||
|
</callout>
|
||||||
|
|
||||||
|
<callout arearefs="co-vx-mod">
|
||||||
|
<para>This is the date when any information in the entry
|
||||||
|
was last modified (<replaceable>YYYY-MM-DD</replaceable>).
|
||||||
|
New entries must not include this field. It should be added
|
||||||
|
upon editing an existing entry.</para>
|
||||||
|
</callout>
|
||||||
|
</calloutlist>
|
||||||
|
</sect2>
|
||||||
|
|
||||||
|
<sect2 id="security-notify-vuxml-testing">
|
||||||
|
<title>Testing your changes to the VuXML database</title>
|
||||||
|
|
||||||
|
<para>Assume you just wrote or filled in an entry for a
|
||||||
|
vulnerability in the package <literal>clamav</literal>
|
||||||
|
that has been fixed in version <literal>0.65_7</literal>.</para>
|
||||||
|
|
||||||
|
<para>As a prerequisite, you need to install fresh versions of the
|
||||||
|
ports <filename role="package">security/portaudit</filename> and
|
||||||
|
<filename role="package">security/portaudit-db</filename>.</para>
|
||||||
|
|
||||||
|
<para>First, check whether there already is an entry for this
|
||||||
|
vulnerability. If there were such entry, it would match the
|
||||||
|
previous version of the package,
|
||||||
|
<literal>0.65_6</literal>:</para>
|
||||||
|
|
||||||
|
<screen>&prompt.user; <userinput>packaudit</userinput>
|
||||||
|
&prompt.user; <userinput>portaudit clamav-0.65_6</userinput></screen>
|
||||||
|
|
||||||
|
<note>
|
||||||
|
<para>To run <command>packaudit</command>, you must have
|
||||||
|
permission to write to its
|
||||||
|
<filename><makevar>DATABASEDIR</makevar></filename>,
|
||||||
|
typically <filename>/var/db/portaudit</filename>.</para>
|
||||||
|
</note>
|
||||||
|
|
||||||
|
<para>If there is none found, you get the green light to add
|
||||||
|
a new entry for this vulnerability. Now you can generate
|
||||||
|
a brand-new UUID (assume it's
|
||||||
|
<literal>74a9541d-5d6c-11d8-80e3-0020ed76ef5a</literal>) and
|
||||||
|
add your new entry to the VuXML database. Please verify
|
||||||
|
its syntax after that as follows:</para>
|
||||||
|
|
||||||
|
<screen>&prompt.user; <userinput>cd ${PORTSDIR}/security/vuxml && make validate</userinput></screen>
|
||||||
|
|
||||||
|
<note>
|
||||||
|
<para>You will need at least one of the following packages
|
||||||
|
installed: <filename role="package">textproc/libxml2</filename>,
|
||||||
|
<filename role="package">textproc/jade</filename>.</para>
|
||||||
|
</note>
|
||||||
|
|
||||||
|
<para>Now rebuild the <command>portaudit</command> database
|
||||||
|
from the VuXML file:</para>
|
||||||
|
|
||||||
|
<screen>&prompt.user; <userinput>packaudit</userinput></screen>
|
||||||
|
|
||||||
|
<para>To verify that the <literal><affected></literal>
|
||||||
|
section of your entry will match correct package(s), issue
|
||||||
|
the following command:</para>
|
||||||
|
|
||||||
|
<screen>&prompt.user; <userinput>portaudit -f /usr/ports/INDEX -r 74a9541d-5d6c-11d8-80e3-0020ed76ef5a</userinput></screen>
|
||||||
|
|
||||||
|
<note>
|
||||||
|
<para>Please refer to &man.portaudit.1; for better understanding
|
||||||
|
of the command syntax.</para>
|
||||||
|
</note>
|
||||||
|
|
||||||
|
<para>Make sure that your entry produces no spurious matches
|
||||||
|
in the output.</para>
|
||||||
|
|
||||||
|
<para>Now check whether the right package versions are matched
|
||||||
|
by your entry:</para>
|
||||||
|
|
||||||
|
<screen>&prompt.user; <userinput>portaudit clamav-0.65_6 clamav-0.65_7</userinput>
|
||||||
|
Affected package: clamav-0.65_6 (matched by clamav<0.65_7)
|
||||||
|
Type of problem: clamav remote denial-of-service.
|
||||||
|
Reference: <http://www.freebsd.org/ports/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html>
|
||||||
|
|
||||||
|
1 problem(s) found.</screen>
|
||||||
|
|
||||||
|
<para>Obviously, the former version should match while the
|
||||||
|
latter one should not.</para>
|
||||||
|
|
||||||
|
<para>Finally, verify whether the web page generated from the
|
||||||
|
VuXML database looks like expected:</para>
|
||||||
|
|
||||||
|
<screen>&prompt.user; <userinput>mkdir -p ~/public_html/portaudit</userinput>
|
||||||
|
&prompt.user; <userinput>packaudit</userinput>
|
||||||
|
&prompt.user; <userinput>lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html</userinput></screen>
|
||||||
|
</sect2>
|
||||||
|
|
||||||
|
<sect2 id="security-notify-noxml">
|
||||||
|
<title>If VuXML still scares you...</title>
|
||||||
|
|
||||||
|
<para>As an easy alternative to writing VuXML, you may opt to add
|
||||||
|
a single line to a different file with much simpler syntax,
|
||||||
|
<filename><envar>PORTSDIR</envar>/security/portaudit-db/database/portaudit.txt</filename>,
|
||||||
|
which resides within the port <filename
|
||||||
|
role="package">security/portaudit-db</filename>, and
|
||||||
|
send a request for review to the Security Officer Team
|
||||||
|
as described on the <ulink
|
||||||
|
url="http://www.freebsd.org/security/#how">FreeBSD
|
||||||
|
Security Information</ulink> page.</para>
|
||||||
|
|
||||||
|
<para>A line in that file consists of four fields
|
||||||
|
separated by <literal>|</literal>, a pipe character.
|
||||||
|
The first field is a &man.pkg.version.1; pattern
|
||||||
|
expression matching the vulnerable packages. The second
|
||||||
|
field contains URLs to relevant information, separated
|
||||||
|
by space characters. The third field is a one-line
|
||||||
|
description of the issue. The fourth and last field
|
||||||
|
is the entry's UUID.</para>
|
||||||
|
|
||||||
|
<para>You may want take a closer look at existing entries in
|
||||||
|
<filename>portaudit.txt</filename> before adding your
|
||||||
|
first line to that file.</para>
|
||||||
|
</sect2>
|
||||||
|
</sect1>
|
||||||
|
</chapter>
|
||||||
|
|
||||||
<chapter id="porting-dads">
|
<chapter id="porting-dads">
|
||||||
<title>Dos and Don'ts</title>
|
<title>Dos and Don'ts</title>
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue