Date: Mon, 29 Mar 2004 23:21:07 +0200 From: Oliver Eikemeier <eikemeier@fillmore-labs.com> To: "Jacques A. Vidrine" <nectar@FreeBSD.org> Cc: FreeBSD Security <security@FreeBSD.org> Subject: Re: cvs commit: ports/multimedia/xine Makefile Message-ID: <40689343.4080602@fillmore-labs.com> In-Reply-To: <20040329201926.GA88529@madman.celabo.org> References: <200403282344.i2SNi6Hq047722@repoman.freebsd.org> <20040329163309.GA81526@madman.celabo.org> <40686785.7020002@fillmore-labs.com> <20040329185347.GB87233@madman.celabo.org> <40687E18.9060907@fillmore-labs.com> <20040329201926.GA88529@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jacques A. Vidrine wrote: > On Mon, Mar 29, 2004 at 09:50:48PM +0200, Oliver Eikemeier wrote: > >>Jacques A. Vidrine wrote: >> >>>The vulnerability database is meant to be comprehensive and >>>informational. It is not a policy document. >> >>I guess it is supposed to be processed by automated tools? It needs a >>clearly defined policy, an informal document is useless for portaudit. > > (BTW, that's ``informational'' not ``informal''.) Sorry, you're right. > I'm sorry, but I don't understand what you mean. Seems to me like > portaudit is doing a great job for its users based on the current > information. Thanks for the compliments, the point is that portaudit is designed to be a non-brainer, telling people to stop using vulnerable ports immediately. On the long run I want to integrate support in pkg_add, so that you could even mark ports as vulnerable on release discs (given that sysinstall gets a current portaudit database). There is not such thing like `it might be ok if you are careful' here. >>>>>I'd prefer to reserve FORBIDDEN for those cases where the ports >>>>>present some danger. Those who want a more strict policy can use >>>>>portaudit or similar, right? >>>> >>>>I guess we have to add a severity tag then, to enable `soft' >>>>vulnerabilities. I have an automated script that barks on unmarked >>>>vulnerabilities, and it can't decide which vulnerability is >>>>`important'. >>> >>>Yes, I wanted to avoid this. Severity is sooo subjective. I prefer >>>that people close to the port make the severity judgement--- if the >>>maintainer or a fellow committer believes the item is severe, then let >>>them mark it FORBIDDEN. That is why I said `FWIW' above--- if you >>>believe it is severe, then please by all means leave it FORBIDDEN. >>>However, I had the impression that you were marking it only because it >>>was listed in the VuXML document. >> >>Sure. Severity is subjective, and I'm not in the position to decide what >>is considered severe enough to advise people to not use it. >> >>The security team are the people who should judge which vulnerabilites are >>severe enough to issue a warning, not the users. That is what they are there >>for. Users can ignore advisories if they decide to do so. > > One could say that the VuXML document *is* the collection of issued > warnings. Users can ignore it, they can peruse it `in the raw' or at > http://vuxml.freebsd.org/, or they can use a tool such as portaudit to > enforce local policy based on the VuXML document. > > It's a bit harder for users' to ignore it when a port is marked > FORBIDDEN. Thus the reason I do not think that *every* issue that > goes into the VuXML document should cause the corresponding port to be > marked FORBIDDEN. Hell, in many cases, the issues depend upon local > configuration or the options with which the port was built. Marking > a port FORBIDDEN unconditionally doesn't make sense if only users who > build it with `-DGAPING_SECURITY_HOLE' are affected :-) > > In short (and to repeat), I do not believe that ports should be > automatically marked FORBIDDEN upon entry into the VuXML document. Essentially this means that I should not automatically add every entry of the VuXML document to the portaudit database, since being listed there means `do not use this port', which is the equivalent to `FORBIDDEN'. >>FORBIDDEN is black-and-white, like an entry in the VuXML database >>is. FORBIDDEN means: do not install this port, or you are on your >>own. What is the meaning of an entry in the VuXML database? > > It means that there are security issues associated with this port, and > that you should be aware of them. Ok, I either need a way to filter out the `unimportant' entries automatically then, or I have to do this by hand. >>You could argue that xine port isn't vulnerable if both scripts >>aren't used. OTOH, why are they installed in the first place? It is >>simple to fix the port: don't install these scripts. > > Yeah, that would be an appropriate action for the port maintainer to > take. > > Just like I do not mark every port with any security issue FORBIDDEN, > I do not romp over port maintainers committing changes unless the > issue is `serious' enough in my opinion. There are several reasons > for this: if it isn't `serious', I'm not likely to find time or > interest to repair it; and it is impossible to be familiar with every > application, and I work under the assumption that `maintainer knows > best'. Since you are the FreeBSD Security Officer, you are the ultimate authority what issues are serious. It seems like there are criteria that have consequences (marking a port FORBIDDEN or not), please note this somewhere in the VuXML document. > [...] > > Well, I feel references that will be in our archives and in our commit > logs are better not pointing to personal web sites (as people...~eik > clearly is). [...] It is an server of the FreeBSD project, not a personal one, and a long standing FreeBSD tradition that people have their projects on their FreeBSD web page, so consider this to be a project page. -Oliver
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40689343.4080602>