From owner-freebsd-vuxml@FreeBSD.ORG Sun Aug 22 20:47:07 2004 Return-Path: Delivered-To: freebsd-vuxml@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 743D716A4CE for ; Sun, 22 Aug 2004 20:47:07 +0000 (GMT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C1C743D2F for ; Sun, 22 Aug 2004 20:47:06 +0000 (GMT) (envelope-from nectar@celabo.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id 2626A54861; Sun, 22 Aug 2004 15:47:06 -0500 (CDT) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 16006-04; Sun, 22 Aug 2004 15:46:54 -0500 (CDT) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id 1BFEB5487F; Sun, 22 Aug 2004 15:46:54 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id B66E26D468; Sun, 22 Aug 2004 15:46:44 -0500 (CDT) Date: Sun, 22 Aug 2004 15:46:44 -0500 From: "Jacques A. Vidrine" To: Oliver Eikemeier Message-ID: <20040822204644.GC17478@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Oliver Eikemeier , FreeBSD-vuxml@FreeBSD.org References: <3AF421B2-F082-11D8-924A-00039312D914@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3AF421B2-F082-11D8-924A-00039312D914@fillmore-labs.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: FreeBSD-vuxml@FreeBSD.org Subject: Re: portaudit wishlist X-BeenThere: freebsd-vuxml@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documenting security issues in VuXML List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 20:47:07 -0000 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 > ja-bugzilla > or > ja-kr-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 php4 php4-cgi php4-cli php4-dtc php4-horde php4-nms mod_php4-twig 4.3.8 versus php4 php4-{cgi,cli,dtc,horde,nms} mod_php4-twig 4.3.8 > - 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 (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 tag. I guess I don't understand this request. That is the purpose of the 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 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 http://archive.site/... 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. ] > Speaking of > references, I would prefer something like CVS Multiple > Vulnerabilities, which means they canbe rendered with a meaningful > line (but most not, so 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 , analogous to the XHTML "alt" attribute found on the element e.g. 10499 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 like "cvs multiple vulnerabilities", what the heck else would we point at in ? :-) 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@celabo.org / jvidrine@verio.net / nectar@freebsd.org [1] The 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 , namely the value 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 to have two children, and . On the other hand, the msgid attribute is a kind of meta-information, so maybe it is not so bad :-)