portaudit wishlist

Jacques A. Vidrine nectar at FreeBSD.org
Sun Aug 22 13:47:07 PDT 2004


On Tue, Aug 17, 2004 at 09:18:33PM +0200, Oliver Eikemeier wrote:
> Ok, things that I think would be really useful (incomplete list):
>
> - csh-style braces.  When this is not the right syntax, this could be
> done with
>   <optional>ja-</optional>bugzilla
> or
>   <alternate><choice>ja-</choice><choice>kr-</choice></alternate>cups
>
> but we have many slave ports which just differ in prefixes/suffixes, and
> it would be easy to expand them when reading the file.
>
> Yes, portaudit does linear searches. Besides, this will greatly diminish
> the size of the database.
>
> I'm even willing to sacrifice glob patterns `*' and `?' for that,
> although they can be quite convenient sometimes.

I deliberately avoided including any "mini syntax" within VuXML.
Each such syntax puts an additional, perhaps insurmountable, burden
on processing tools.  For example, including such things makes it
practically impossible to use XSLT to translate VuXML into other XML
formats such as XHTML, or to build accurate XQuery/XPath expressions.
A less severe case is that of a package audit tool that uses a
database backend (SQL, db4, whatever) for lookups: it must first
expand these csh-style constructs before entering them into the
database.

These things are maybe not deal killers (well, the XSLT issue is very
close), but the real problem is that this simply adds complexity to the
format with no benefit.   The size savings is insignificant, and it is
highly arguable that it is preferable to edit or read even in extreme
cases such as

      <package>
        <name>php4</name>
        <name>php4-cgi</name>
        <name>php4-cli</name>
        <name>php4-dtc</name>
        <name>php4-horde</name>
        <name>php4-nms</name>
        <name>mod_php4-twig</name>
        <range><lt>4.3.8</lt></range>
      </package>

versus

      <package>
        <name>php4</name>
	<name>php4-{cgi,cli,dtc,horde,nms}</name>
        <name>mod_php4-twig</name>
        <range><lt>4.3.8</lt></range>
      </package>

> - 1.* notation as the `smallest 1.x version possible'. 1.a is not the
> smallest, besides it is not completely transparent why .a is chosen in
> the range. When the `*' is the problem, this could be easily changed to
> a random character, or even a <ger></ger> (greater equal range) tag (ok,
> the name is silly), but I want to have some standard way like >= 1.* <
> 2.* to match all 1.x and nothing else. No, I don't think >= 1.a < 2.a is
> good here.

I understand your motivation here, but I want to be careful about
adding extraneous notation.  Honestly, I do see the *convenience* of
using e.g. `2.*'.  It requires less thinking :-) As you well know I
have made the mistake of specifying `2' when `2.a' or similar was
needed, and I think that if `2.*' would have been "available" I
probably would have used it instead.  I assume this goes double for
anyone less familiar with VuXML, and those who are maybe "copying" from
another entry.

I'm a little nervous about people seeing generated documentation with
`*' and thinking it means something other than it means.  But, as we
discussed previously, I really cannot think of a better character.
Maybe I'm overly concerned.

So basically I think we should introduce this in VuXML 1.2.  I'd like
to hear some comments from others about it, especially from the point
of view of the user reading content generated from VuXML.

> - make `discovery' optional. It's a nice-to-have, but sometimes hard to
> find out, and dummy entries like entry = discovery do not help anyone.
> (ok, superseeded by another thread).
>
> - make `description' optional. It is in the way of `quick' entries which
> should be researched later. Of course it is acceptable to fill it with a
> dummy value, but in this case it shouldn't be present IMHO and the dummy
> value should be provided by the rendering code. Or will an empty tag do?

Let's cover both of these in the other thread, because I think they are
kinda related.

> - make a `severity' field available. Of course it might be inaccurate,
> and software might want to ignore it and provide it's own data. Yet it
> is useful when you only have time for a quick glance (notify me
> immediately of severe vulnerabilities, all others should only appear in
> fridays report). It is a valuable guidance for the users, although I'm
> aware it is very error-prone.

This is a policy issue, and does not belong in the FreeBSD VuXML
document.  I think adjunct documents/database for that purpose are
great.  If some were available and well-maintained, I would for example
want to provide a sidebar on www.vuxml.org for each vulnerability
showing the ratings.

We've already discussed this in the thread which includes the message
http://lists.freebsd.org/pipermail/cvs-ports/2004-March/031704.html.
I'm not sure it is useful to go over the same ground again.

I think it is likely you will say that the Security Officer should
assign some severity.  To pre-respond :-) I'll say that the security
team's perspective is that either (a) you understand the security
issue, in which case you can decide whether it is a risk for you to
run the software or not; or (b) you don't understand the security
issue, in which case you should not run the software.

That said, I wouldn't rule out one day publishing an adjunct document
with some coarse-grained ratings.  But I wouldn't claim that it was
the final word on severity on risk.  In any case, I'm not prepared to
do that now, and neither are most of my colleagues doing this kind of
security work for other operating systems/ distributions/ what have
you.  In fact, I think it is far more likely that we will wait until
a certain well-known organization completes their risk assessment
system, and use that as an adjunct.

> - add a classification into remote/local exploitable

On the one hand, I feel this should be handled in the narrative
description and that it is otherwise just another facet of the
severity rating.  On the other hand, I can imagine someone deciding
that it was OK e.g. to install any ports that did not have a
*remotely* exploitable vulnerability.

My instinct tells me this too should be adjunct, at least
for now.  Why would we include remotely/locally, but not
authenticated/unauthenticated, application privileges/system
privileges, user privileges/superuser privileges, or other such
aspects?  If you have a server with a vulnerability that lets someone
who has a local account to get some other access, would you record
that as local or remote?

Yes, I think it is misleading to apply such tags which a user might
take as an absolute judgement when in fact they just need to read the
description.

> - add a `fixed' field that lists a version where the vulnerability is
> fixed. This could be used for a recommendation message, like "upgrade to
> version xxx" or "no upgrade is available, please deinstall the port or
> proceed with caution".
> This could also realized as an alternate <lt> tag.

I guess I don't understand this request.  That is the purpose of the
<affected> element and children.

> - Also we should add tags for the most popular references.

VuXML 1.2 will include OSVDB (and almost any other you care to
suggest right now).  In addition, the <references> element will be
parametized so that new reference types can be added `between' VuXML
DTD updates.  VuXML tools are expected to render "unknown" reference
types in the obvious fashion, e.g. old tools might render <mlist
msgid="foo at bar...">http://archive.site/...</mlist> in a references
table as

    mlist   http://archive.site/...

With parameterization, adding a FooDB element while remaining valid is
accomplished with an internal DTD subset in the usual fashion, e.g.

  <!DOCTYPE vuxml PUBLIC "-//vuxml.org//DTD VuXML 1.1//EN"
                  "http://www.vuxml.org/dtd/vuxml-1/vuxml-11.dtd"
  [
  <!ENTITY % vuxml.referencesextras "| %vuxml.foodb.qname;" >
  <!ENTITY % vuxml.foodb.qname "%vuxml.pfx;foodb" >
  <!ELEMENT %vuxml.foodb.qname; ( #PCDATA ) >
  <!ATTLIST %vuxml.foodb.qname; %vuxml.Common.attrib; >
  ]


> Speaking of
> references, I would prefer something like <bid num="10499">CVS Multiple
> Vulnerabilities</bid>, which means they canbe rendered with a meaningful
> line (but most not, so <bid num="10499"/> is legal too).

I have two problems with this suggestion, both of which may be fixable:

  (a) Important stuff should be element content, and not attributes. [1]
  (b) When rendering a Bugtraq bug ID, the bug ID *is* the meaningful
      thing and must be displayed in a "meaningful line".  The title or
      description of the bug ID is meta-data.

A modification of your proposal that wouldn't have these problems
would be to add a descriptive attribute that can be used on any child of
<references>, analogous to the XHTML "alt" attribute found on the <img>
element e.g.

   <bid description="CVS Multiple Vulnerabilities">10499</bid>

Such descriptions could be rendered inline, as footnotes, or as popups
(e.g. XHTML hover).

However, I really don't see this providing much value, especially
considering that the vast majority of such references will not be
filled in.  Your example might be particularly poor.  Assuming
that we're talking about an entry with a <topic> like "cvs
multiple vulnerabilities", what the heck else would we point at in
<references>? :-)  I'm sure you can find a few good examples, but I
imagine those will be few and stretched.

The whole point of VuXML is to give enough information but not too
much :-)  ``Too much'' is anything that is not likely to be supplied in
the vast majority of cases.

> Ok, too many threads now. I have too look into this a little closer.

Thanks, Oliver!  Cheers,
-- 
Jacques Vidrine / nectar at celabo.org / jvidrine at verio.net / nectar at freebsd.org


[1] The <mlist> element uses attribute data for what might be
    considered "important stuff" (msgid, the message ID).  However,
    this is to keep within a "meta content model" for <references>,
    namely the <type>value</type> model so that VuXML tools can be
    dumb and just output or search (type, value) tuples.  If it
    weren't for this, I probably would have specified <mlist> to have
    two children, <msgid> and <url>.  On the other hand, the msgid
    attribute is a kind of meta-information, so maybe it is not so bad
    :-)


More information about the freebsd-vuxml mailing list