Re: cvs commit: ports/multimedia/xine Makefile

From: Jacques A. Vidrine (nectar_at_FreeBSD.org)
Date: 03/29/04

  • Next message: Oliver Eikemeier: "Re: cvs commit: ports/multimedia/xine Makefile" 
    Date: Mon, 29 Mar 2004 14:19:26 -0600
To: Oliver Eikemeier <eikemeier@fillmore-labs.com>

    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''.)

    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.

    > >>>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.

    > 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.

    > 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'.

    > >>>>http://people.freebsd.org/~eik/portaudit/fde53204-7ea6-11d8-9645-0020ed76ef5a.html
    > >>>
    > >>>By the way, I'd appreciate it if you'd point to the VuXML site instead
    > >>>(the URLs are `permanent').
    > >>>
    > >>> http://vuxml.freebsd.org/
    > >>> http://vuxml.freebsd.org/fde53204-7ea6-11d8-9645-0020ed76ef5a.html
    > >>
    > >>These are generated by the same script that generates the portaudit
    > >>database, so they will never go out of sync.
    > >
    > >I'm not sure how to take that response :-) I'd prefer to use the
    > >permanent FreeBSD URL, which points to the VuXML site which is near
    > >real-time updated and where I'll be focusing browsing experience
    > >enhancements. Is there something in particular missing? (contributions
    > >welcome!)
    >
    > No, but the former URLs are permanent too, have
    > <http://people.freebsd.org/~eik/portaudit/1ed556e6-734f-11d8-868e-000347dd607f.html>
    > which is mentioned in
    > <http://www.freebsd.org/cgi/mid.cgi?db=mid&id=200403111145.i2BBjQfa088098@repoman.freebsd.org>,
    > are guaranteed to be synchronized with the portaudit database and contain
    > the same information. I have to generate them anyway, so what's the point?

    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). I guess you have some reason to disagree but are unwilling
    to state it. *shrug* Of course you can do whatever you like.

    Cheers, 

    -- 
Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
  • Next message: Oliver Eikemeier: "Re: cvs commit: ports/multimedia/xine Makefile"

    Relevant Pages

    • Re: cvs commit: ports/multimedia/xine Makefile
      ... an informal document is useless for portaudit. ... > enforce local policy based on the VuXML document. ... > goes into the VuXML document should cause the corresponding port to be ... Since you are the FreeBSD Security Officer, ...
      (FreeBSD-Security)
    • Re: cvs commit: ports/multimedia/xine Makefile
      ... the point is that portaudit is designed to ... >>enforce local policy based on the VuXML document. ... >>goes into the VuXML document should cause the corresponding port to be ... >>Just like I do not mark every port with any security issue FORBIDDEN, ...
      (FreeBSD-Security)
    • Re: cvs commit: ports/multimedia/xine Makefile
      ... >>is considered severe enough to advise people to not use it. ... > enforce local policy based on the VuXML document. ... > goes into the VuXML document should cause the corresponding port to be ...
      (FreeBSD-Security)
    • Re: [RE: Access to well-known ports on Win2K]
      ... communication typically uses the ephemeral port range. ... policy - works for all users of the machine; and can allow or block access ... many routes for deployment as you mention: Group Policy; Local Security ... > IPSec Policy Agent service then the IPSec policy is no longer active. ...
      (Focus-Microsoft)
    • RE: [RE: Access to well-known ports on Win2K]
      ... destination port and ANY source port. ... > policy - works for all users of the machine; ... > Local Security ... >> could use an IPSec policy and deploy to all users to block ...
      (Focus-Microsoft)