Date: Sun, 22 Aug 2004 23:39:47 +0200 From: Oliver Eikemeier <eikemeier@fillmore-labs.com> To: "Jacques A. Vidrine" <nectar@FreeBSD.org> Cc: FreeBSD-vuxml@FreeBSD.org Subject: Re: portaudit wishlist Message-ID: <C9F55B3A-F483-11D8-8CAA-00039312D914@fillmore-labs.com> In-Reply-To: <20040822204644.GC17478@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jacques A. Vidrine wrote:
> 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>
It should be trivial to deal with the <alternate> tag in XSLT, the same
should be possible with <optional>, and for entering them into databases
you have to render the stuff anyway. Readability of the XML code is a
non-issue, since it is designed to be machine-readable, not
human-readable. portaudit is designed to be lightweight and work without
a database, so it does linear searches on all systems. I might change
that, but that's the way things currently are, so what's the problem
here?
>> - 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.
As stated before: The vuxml entry doesn't have to use `*', nor do you
have to use it in the rendered version. It is perfectly legal to render
this as `>= 2.x' with a cursive x. We should just have _something_. If
you prefer, we can even use <floor> an <ceil> instead of <ge> and <lt>
or something similar that clarifies truncation is used. Anyway, the way
things currently are works for me, and avoids bugs.
> 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.
Uhm, you don't need vuxml 1.2 for that, this is perfectly legal in vuxml
since 1.0.
>> - 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.
I can't really follow your rationale here. You claim that because it
can't be done perfectly, it shouldn't be done at all. I would find it
incredibly useful to get some categorization into `dangerous',
`important' and `minor', even when it's wrong sometimes. As discussed
before: You usually have a pretty good idea whether a vulnerability is
severe or not, you just don't want to tell anybody.
I consider this valuable to give users a chance to customize the
notification scheme of portaudit, and why shouldn't this information
find its place in the vuxml database? Make this tag optional, so you
don't have to fill in anything when you on't feel like it.
>> - 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?
umh, local of course?
> 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.
Not everyone has the time to review every description. Besides, the
description might be as wrong or misleading as the tags mentioned. If
you say "users have to understand the system fully or they shouldn't run
the software" you basically state "FreeBSD is only for experts". I'm
just trying to make some often asked questions machine readable. For
example when I run portaudit on a server with no users, I might decide
to care for local exploitable vulnerabilities only ever friday, while I
have to handle remote exploitable vulnerabilities immediately. This
system is not perfect, but usable. You give users basically no way to
filter the information, which would be a valuable feature. One one hand
you state users have to be knowledgeable to run a system, one the other
you claim they might take tags `as an absolute judgement'. In this case
reading the (possibly wrong) description might not improve anything.
>> - 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.
There is no information whether there is an update available (and since
which date the vulnerability is fixed), or if I simply have to deinstall
the software and use a different product.
>> 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).
Ok, since we have to be backwards compatible, let's do it that way.
> 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.
xfdb does it that way, and I like it. It's especially useful for mailing
list posts, to see whether they contain an advisory or an exploit, for
entries that cover multiple vulnerabilities (to distinguish the CVE
references) and to filter out those `Updated packages fix multiple
vulnerabilities' references for other operating systems.
> 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.
This could be automated by the tool that makes entries, or even by a
tool that adds missing descriptions, so it is likely to be supplied.
-Oliver
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C9F55B3A-F483-11D8-8CAA-00039312D914>