Date: Wed, 25 Aug 2004 13:05:25 -0500 From: Jacques Vidrine <nectar@FreeBSD.org> To: Oliver Eikemeier <eikemeier@fillmore-labs.com> Cc: FreeBSD-vuxml@FreeBSD.org Subject: Re: portaudit wishlist Message-ID: <56E15C66-F6C1-11D8-9236-000A95BC6FAE@FreeBSD.org> In-Reply-To: <941610FA-F515-11D8-8CAA-00039312D914@fillmore-labs.com> References: <941610FA-F515-11D8-8CAA-00039312D914@fillmore-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 23, 2004, at 10:03 AM, Oliver Eikemeier wrote: > Jacques A. Vidrine wrote: > >> On Sun, Aug 22, 2004 at 11:39:47PM +0200, Oliver Eikemeier wrote: >>> 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. >> >> One of your concerns was bloat, and I think using >> <alternate>/<optional> like this would be just as much bloat. The >> only redeeming quality of the csh-style syntax was brevity (but as I >> said, I don't think that's a sufficient reason to use it). > > Bloat as in `linear search'. It's easy to render <alternate> to > csh-style braces. OK, now I understand what you are talking about. I'm sorry, I think you tried to tell me several times already, but I didn't understand. Today there are about 245 <name> elements, and I'd guess that maybe 40 could be replaced with a syntax such as you suggest. However, I don't think a 17% reduction in entries to speed up a linear search is worth the uglification. The first rule of optimization is, well, "don't do it", but one of the other top rules is to optimize by selecting the right algorithm, rather than attempting to speed up an inherently slower one. [...] >>> Uhm, you don't need vuxml 1.2 for that, this is perfectly legal in >>> vuxml >>> since 1.0. >> >> No, it is not. You can of course have a *valid* VuXML document with >> `1.*' or even `@#$@% mary had a little lamb' as content for the >> <range> >> child elements, but that doesn't make it a legal or proper VuXML >> document. The DTD is only part of the specification. The other part >> is >> described in the DTD comments. > > I can only find `The version ranges given must not overlap.' Other > pointers? I still think this is a proper vuxml range specification. > How a platform defines (and sorts) version numbers isn't handled in > the vuxml specification. You are right, this could only be specified per platform. I guess I'm confusing it with VuXML point releases, because changing the syntax also means tools have to adapt. For example, vxquery uses code from pkg_install which does not "understand" `1.*'. This just meants that vxquery needs to be updated. portaudit already groks it, and I don't think it matters for vuxml.org's rendered pages. So, I'll update vxquery and then it should be OK to use. Tangent --- maybe the version comparison code should be available in a library. [...] > It is useful to have the ability to mark vulnerabilities as `minor', > like for example CAN-2004-0777. Hmm, I think that was a mistake. I feel quite certain that a significant number of installations actually have DEBUG_LOGIN set. [...] >> I think that any severity rating system should be seperate from the >> VuXML documentation to allow for multiple such systems and policies, >> particularly as practices in this area evolve. > > I don't think so. Either we have a common view on vulnerabilities, or > we don't. Well, we disagree, Oliver. > I guess we should make vuxml the official database format, portaudit > the official tool and be set. What are `multiple systems and policies' > in this context? A FreeBSD Project mantra is `tools, not policy'. `multiple systems and policies' means multiple tools. > a severity rating is advisory only, and could be used or ignored > however the system thinks is fit. What's the point when FreshPorts has > an other severity level that portaudit? Perhaps FreshPorts (or whatever) has a rating system that better fits what some users need to accomplish. > Or should it use the portaudit severity ranking? I can't understand > your problems here. Conversely, I do not understand yours. :-( >>>>> - 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? >> >> Funny you should say `of course'. I would have classified it as >> remote. I picked this example from some correspondence involving >> several colleagues, and guess what: the answers were mixed. Which is >> `of course' my point. > > You have border cases in every system. I think it is not a border case, but fundamental. The fact that you think it is a border case and I think it is fundamental is indicative of our lack of agreement in this area. > Just denying to add useful features because some entries could be > erroneous isn't helpful. You think it is useful, I don't. I almost feel it is harmful, in fact :-) You have the freedom to implement those features you think are useful, and I have the freedom to ignore your insistence that I need to do something I consider not useful. > Users could use this information, even when it's not 100% correct. Sure. There is always the possibility of flaws. I suggest treating every issue as severe unless one knows better (for herself). This is called "fail closed", and I think that it is appropriate for a project such as ours. > Even the <range> entries in vuxml are not 100% correct, so what? Such entries should be considered bugs. Or was this a rhetorical question? [...] > Ok, back to my own database specification then? We have just a > different view on our user base, and I think you fail to address some > needs. Not everybody is a purist here, some `just want to have the job > done', even when this means to err once or twice. You already have your own *database* specification, and you should continue to use and evolve it. I think that issues should be *documented* in VuXML. Did you mean something else? [...] >> Maybe you can describe this a bit more fully? (BTW, Can you make a >> separate thread for each of your proposals?) I felt that the affected >> ranges were sufficient, but if there is a better way let's hear it. > > There is no way to deduce from the VuXML document alone whether a > fixed version exists (like in port<1.5: is there a port-1.5 in the > tree or not?). So basically the user has to do the research whether > s/he could just upgrade or has to deinstall the port completely (or > live with the vulnerability). I understand what you are saying, but I was looking for a proposal here. Frankly, what we have seems appropriate. Either a non-vulnerable version --- older or newer --- is available, or it isn't. But of course I haven't seen a good alternative approach. [...] >> Well, I'm not sure I'm convinced. But let's try an example. >> >> <references> >> <cvename description="BMP heap overflow">CAN-2004-0691</cvename> >> <cvename description="XPM crash">CAN-2004-0692</cvename> >> <cvename description="GIF crash">CAN-2004-0693</cvename> >> >> <url>http://www.trolltech.com/developer/changes/changes-3.3.3.html</ >> url> >> <url>http://scary.beasts.org/security/CESA-2004-004.txt</url>; >> </references> >> >> Is this the kind of thing you mean? > > More or less. Since these CVE references have no title yet, they would > be shown as simple URLs. For my part, I would want to *always* show the URLs, and the description separately (extra line or column, "hover" pop-up, whatever). > But you could have <url description="Trolltech - Changes 3.3.3"> > http://www.trolltech.com/developer/changes/changes-3.3.3.html</url>. >> I wonder if it will really be >> used much *shrug* (by authors or users). I'd like to know what you >> mean by `a tool that adds missing descriptions'. Are you thinking >> of following the references and snarfing the <title> or similar? > > Jup, with a possibility to edit or deny it when it is too meaningless. > >> That might be neat. But, it would create two different meanings >> for this attribute: (a) editorial description, i.e. to disambiguate >> multiple similar references to CVE names, source code, whatever; (b) >> the referenced item's description, e.g. <title> for HTML documents, >> Subject: for email. I'm not sure I like that. As you seem to point >> out, (b) could be largely automated, so I'm not sure it is worth >> storing it in the document. Then when rendering a document, how will >> a reader know that what she sees is (a) or (b)? > > Probably (b) or the url is fine here. (a) is too much work in the > general case. So I guess what you are proposing is a tool that reads a VuXML document, snarfs all the remote reference titles, and spits out a new VuXML document with the titles inserted? In effect, this is just caching remote reference titles, isn't it? It seems to me (a) is useful to include in VuXML since it can only be provided by authors, while (b) doesn't seem to be very useful except possibly in rendering... and I have a feeling that a large number (maybe majority) of references have titles that are not well suited to being lifted out of context. CVE names are a particularly good example. All of them will say 'CAN-YYYY-XXXX (under review)' or 'CVE-YYYY-XXXX', which is useless. Advisories are often plain text, and so have no title that can be automatically snarfed. Web-based mailing list archives have additional spam at best, and often are completely useless (e.g. ``SecurityFocus BUGTRAQ Mailing List: BugTraq'' or ``Neohapsis Archives - Red Hat Linux - #0003 - [RHSA-2004:158-01] Updated cadaver package fixes security vulnerability in neon''). Yes, upon further reflection, I think automatically filling out the information in (b) is not a great idea. But I think (a) could be really useful in some cases... except that, I think authors probably would not fill it out often. >> One more thing: I suggested `description' as the attribute name, but I >> have second thoughts. I believe it might be better to pick something >> that is not also an element name, and perhaps `description' is a >> little too much typing. > > Whatever you like. I suppose we'll wait for inspiration, then :-) > Since entries should be done by tools, I don't care how much typing is > necessary. Well *in fact* manual editing is how VuXML documents are created/edited, along with billions of other XML and SGML documents, regardless of the availability of tools. This is kind of beside the point, but you seem to like to say this in justification of one thing or another when it is simply wrong. Cheers, -- Jacques A Vidrine / NTT/Verio nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56E15C66-F6C1-11D8-9236-000A95BC6FAE>