Date: Mon, 23 Aug 2004 09:09:49 -0500 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: Oliver Eikemeier <eikemeier@fillmore-labs.com> Cc: FreeBSD-vuxml@FreeBSD.org Subject: Re: portaudit wishlist Message-ID: <20040823140949.GL27355@madman.celabo.org> In-Reply-To: <C9F55B3A-F483-11D8-8CAA-00039312D914@fillmore-labs.com> References: <20040822204644.GC17478@madman.celabo.org> <C9F55B3A-F483-11D8-8CAA-00039312D914@fillmore-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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). > Readability of the XML code is a > non-issue, since it is designed to be machine-readable, not > human-readable. No, that's really not correct. XML is not necessarily user-readable, but it may certainly be human-readable. Or do you think that all our doc committers that work on the web site or hand book and so forth work in "write-only" mode? (rhetorical question) > 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? I don't know, what *is* the problem here? What problem are you trying to solve with this new syntax? It doesn't seem to be readability (the csh syntax and <alternate>/<optional> elements are both worse for readability). You mentioned space, but I don't believe that's an issue, and you seem to not either. > 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. Oh, that's a nice idea. > 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. Yeah, I prefer your original proposal. > >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. 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. > >>- 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 don't think you read and understood what I wrote. Let me try to be clearer: the security team does not currently assign severity to security advisories or VuXML entries, and has no plans to do so. Rather, we believe that all of these security notices should be acted upon. > 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. 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. > >>- 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. > >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. Your ``reasoning'' makes me dizzy. Look Oliver, knock yourself out: come up with your own severity rating scheme and implement it. Stop bugging the security team to do it, I've already explained that we will not at this time. > >>- 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. 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. [... snip: adding `description's to each reference ...] > 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. 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? 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? 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)? 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. Cheers, -- Jacques Vidrine / 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?20040823140949.GL27355>