From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 06:15:27 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 157AF16A4D0; Mon, 29 Mar 2004 06:15:27 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9C3443D1D; Mon, 29 Mar 2004 06:15:26 -0800 (PST) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (nectar@localhost [127.0.0.1]) i2TEFQbv036004; Mon, 29 Mar 2004 06:15:26 -0800 (PST) (envelope-from security-advisories@freebsd.org) Received: (from nectar@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2TEFQrC036003; Mon, 29 Mar 2004 06:15:26 -0800 (PST) (envelope-from security-advisories@freebsd.org) Date: Mon, 29 Mar 2004 06:15:26 -0800 (PST) Message-Id: <200403291415.i2TEFQrC036003@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: nectar set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Subject: FreeBSD Security Advisory FreeBSD-SA-04:06.ipv6 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Reply-To: security-advisories@freebsd.org List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 14:15:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:06.ipv6 Security Advisory The FreeBSD Project Topic: setsockopt(2) IPv6 sockets input validation error Category: core Module: kernel Announced: 2004-03-29 Credits: Katsuhisa ABE, Colin Percival Affects: FreeBSD 5.2-RELEASE Corrected: 2004-03-29 14:01:33 UTC (RELENG_5_2, 5.2.1-RELEASE-p4) CVE Name: CAN-2004-0370 FreeBSD only: YES For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background IPv6 is a new Internet Protocol, designed to replace (and avoid many of the problems with) the current Internet Protocol (version 4). FreeBSD uses the KAME Project IPv6 implementation. Applications may manipulate the behavior of an IPv6 socket using the setsockopt(2) system call. II. Problem Description A programming error in the handling of some IPv6 socket options within the setsockopt(2) system call may result in memory locations being accessed without proper validation. While the problem originates in code from the KAME Project, it does not affect other operating systems. III. Impact It may be possible for a local attacker to read portions of kernel memory, resulting in disclosure of sensitive information. A local attacker can cause a system panic. IV. Workaround Do one of the following: 1) Disable IPv6 entirely by following these steps: - Remove or comment out any lines mentioning `INET6' from your kernel configuration file, and recompile your kernel as described in . - Reboot your system. 2) If all untrusted users are confined within a jail(8), ensure that the security.jail.socket_unixiproute_only sysctl is set to 1 and verify that no IPv6 sockets are currently open: # sysctl security.jail.socket_unixiproute_only=1 # sockstat -6 This will restrict jailed processes to creating UNIX domain, IPv4, and routing sockets, which are not vulnerable to this problem; note however that processes inside a jail may still be able to inherit IPv6 sockets from outside the jail, so this may not be sufficient for all systems. V. Solution Do one of the following: 1) Upgrade your vulnerable system to the RELENG_5_2 security branch dated after the correction date. 2) To patch your present system: a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:06/ipv6.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:06/ipv6.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the kernel as described in and reboot the system. d) Install updated kernel headers. # cd /usr/src/include # make install VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_5_2 src/UPDATING 1.282.2.12 src/sys/netinet6/ip6_output.c 1.71.2.2 src/sys/netinet/ip6.h 1.10.2.1 src/sys/conf/newvers.sh 1.56.2.11 - ------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAaC6kFdaIBMps37IRAiCBAJ9ATb8FTKysuJvwlU8E0YOArWwP1gCcCCpw rK7VXiZuLwD1zZmBepSHCt4= =FLqJ -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 11:50:59 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AADC16A4CE; Mon, 29 Mar 2004 11:50:59 -0800 (PST) Received: from postman.arcor.de (newsread1.arcor-online.net [151.189.0.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA4A743D5A; Mon, 29 Mar 2004 11:50:58 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i2TJoqck004859 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 29 Mar 2004 21:50:57 +0200 (MEST) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1B82mX-000J8S-35; Mon, 29 Mar 2004 21:50:49 +0200 Message-ID: <40687E18.9060907@fillmore-labs.com> Date: Mon, 29 Mar 2004 21:50:48 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <200403282344.i2SNi6Hq047722@repoman.freebsd.org> <20040329163309.GA81526@madman.celabo.org> <40686785.7020002@fillmore-labs.com> <20040329185347.GB87233@madman.celabo.org> In-Reply-To: <20040329185347.GB87233@madman.celabo.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: cvs-ports@FreeBSD.org cc: FreeBSD Security cc: cvs-all@FreeBSD.org cc: ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: FreeBSD Security List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 19:50:59 -0000 Jacques A. Vidrine wrote: > On Mon, Mar 29, 2004 at 08:14:29PM +0200, Oliver Eikemeier wrote: > >>Jacques A. Vidrine wrote: >> >>>On Sun, Mar 28, 2004 at 03:44:06PM -0800, Oliver Eikemeier wrote: >>> >>>>eik 2004/03/28 15:44:06 PST >>>> >>>>FreeBSD ports repository >>>> >>>>Modified files: >>>> multimedia/xine Makefile >>>>Log: >>>>Mark forbidden due to an entry in the VuXML database. Don't >>>>forget to add the version which fixes the issues there. >>> >>>FWIW: >>> >>>I didn't mark this port FORBIDDEN when I added the issue to the >>>database because some issues are not very severe. For example, this >>>issue has practically no impact on single user systems, and quite >>>possibly no impact on any FreeBSD user anywhere. Marking the port >>>FORBIDDEN in this case seems extreme. >> >>It's in the official FreeBSD vulnerability database. > > 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. >>>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. 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? 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. > I suppose we could consider a very coarse-grained severity rating, but > I'd rather not. I guess such a discussion should take place over on > freebsd-security@. Follow-up to security@ then. >>>>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 which is mentioned in , 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? -Oliver From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 12:19:27 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E852016A4CE for ; Mon, 29 Mar 2004 12:19:27 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6061643D1D for ; Mon, 29 Mar 2004 12:19:27 -0800 (PST) (envelope-from nectar@celabo.org) 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 088925485D; Mon, 29 Mar 2004 14:19:27 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 9A0DE6D455; Mon, 29 Mar 2004 14:19:26 -0600 (CST) Date: Mon, 29 Mar 2004 14:19:26 -0600 From: "Jacques A. Vidrine" To: Oliver Eikemeier Message-ID: <20040329201926.GA88529@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Oliver Eikemeier , FreeBSD Security 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40687E18.9060907@fillmore-labs.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 20:19:28 -0000 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 > > which is mentioned in > , > 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 From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 13:21:15 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C2D116A4D3; Mon, 29 Mar 2004 13:21:15 -0800 (PST) Received: from postman.arcor.de (postman2.arcor-online.net [151.189.0.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id C351543D1D; Mon, 29 Mar 2004 13:21:14 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i2TLLBko007928 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 29 Mar 2004 23:21:13 +0200 (MEST) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1B84Bw-000CFS-Ni; Mon, 29 Mar 2004 23:21:08 +0200 Message-ID: <40689343.4080602@fillmore-labs.com> Date: Mon, 29 Mar 2004 23:21:07 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: "Jacques A. Vidrine" 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> In-Reply-To: <20040329201926.GA88529@madman.celabo.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 21:21:15 -0000 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 From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 14:18:29 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 940D216A4CE; Mon, 29 Mar 2004 14:18:29 -0800 (PST) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1C5E43D31; Mon, 29 Mar 2004 14:18:28 -0800 (PST) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id D8C951676C7; Tue, 30 Mar 2004 00:18:27 +0200 (CEST) Received: from gmx.net (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i2TMIQAj001961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2004 00:18:27 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) Message-ID: <4068A0AF.2090807@gmx.net> Date: Tue, 30 Mar 2004 00:18:23 +0200 From: Michael Nottebrock User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, de-de MIME-Version: 1.0 To: Oliver Eikemeier 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> <40689343.4080602@fillmore-labs.com> In-Reply-To: <40689343.4080602@fillmore-labs.com> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB4BBD23C646BC8863A0BBF5E" X-Virus-Scanned: by amavisd-new cc: "Jacques A. Vidrine" cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 22:18:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB4BBD23C646BC8863A0BBF5E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > 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'. Why? I mean, seriously, if I choose to install portaudit and portaudit's presence prevents me from installing ports that's okay, but enforcing this even when I _don't_ want to use portaudit it's not, IMHO. Actually, I always thought portaudit was all about providing a way of making ports off-limits _without_ CVS being involved. So I agree with Jacques here, portaudit and FORBIDDEN should remain separate. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --------------enigB4BBD23C646BC8863A0BBF5E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows 2000) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAaKCyXhc68WspdLARAqdAAKCFJ5PN+cdTN08svrb1Hwuplz89zgCePbzn aDSPx0TPSjDhXdQhyVXtiy4= =u02m -----END PGP SIGNATURE----- --------------enigB4BBD23C646BC8863A0BBF5E-- From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 14:40:13 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8271116A4CE for ; Mon, 29 Mar 2004 14:40:13 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF72643D54 for ; Mon, 29 Mar 2004 14:40:12 -0800 (PST) (envelope-from nectar@celabo.org) 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 7CD905487E; Mon, 29 Mar 2004 16:40:12 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 1730D6D455; Mon, 29 Mar 2004 16:40:12 -0600 (CST) Date: Mon, 29 Mar 2004 16:40:12 -0600 From: "Jacques A. Vidrine" To: Oliver Eikemeier Message-ID: <20040329224011.GA94303@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Oliver Eikemeier , FreeBSD Security 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> <40689343.4080602@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40689343.4080602@fillmore-labs.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 22:40:13 -0000 On Mon, Mar 29, 2004 at 11:21:07PM +0200, Oliver Eikemeier wrote: > Jacques A. Vidrine wrote: > >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. Speaking of pkg_add, I was thinking it might make sense to add hooks to these utilities, either in the form of loading dynamic objects or just invoking shell scripts. It seems that knu@ would be able to use these for portupgrade, we could use them for portaudit and VuXML related items, and power users could use them to invent their own local uses. But, that's a discussion for ports@ I guess. > >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. Personally, I was quite pleased with the way that you have it set up: if users install portaudit, then they will be warned daily about ports that they have installed; and attempting to build the port results in much the same thing as FORBIDDEN. (I guess I could have some misunderstanding, though.) Without portaudit, we have the current situation. The only ports marked FORBIDDEN are those where someone believed that problems are serious enough to mark it so. I often mail folks when I enter their port into VuXML. I intend to automate this nagging, but just haven't gotten around to it yet. > >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. I'm just a guy. The Security Team are just more guys (but very helpful and clueful ones--- thanks guys!!). We want and need coordination with the ports maintainers: they (should) have a level of expertise with their particular applications that we simply cannot have for the 10,000+ ports. Not to mention, ports maintainers can be touchy. As can we all :-) > It seems like there are criteria that have consequences (marking > a port FORBIDDEN or not), please note this somewhere in the VuXML > document. I'd like to take a step before committing myself (and any would-be VuXML contributor) into assigning a severity to every issue. If there is rough consensus from the ports community (committers and maintainers) that any documented security issue is grounds enough to mark a port FORBIDDEN, then we'll follow the policy that (entry in VuXML document) == (port must be marked FORBIDDEN). This seems to be your stance, and I do not think it is unreasonable. Although I made the comment earlier that I don't share the opinion, it is nonetheless attractive because it is simple :-) > >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. By all means, there's certainly nothing wrong with hosting your project on your own page. But Oliver, when one visits the URLs that you've posted, one is presented with content that, in the vast majority of cases, was not authored by you and has little association with `portaudit'. So, I ask again that you please consider using the vuxml.freebsd.org URLs when displaying URLs for VuXML entries. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 14:54:07 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9369216A4CE; Mon, 29 Mar 2004 14:54:07 -0800 (PST) Received: from postman.arcor.de (newsread1.arcor-online.net [151.189.0.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id E64F543D41; Mon, 29 Mar 2004 14:54:06 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i2TMs5ck019208 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 30 Mar 2004 00:54:05 +0200 (MEST) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1B85dq-000OUh-FZ; Tue, 30 Mar 2004 00:54:02 +0200 Message-ID: <4068A90A.7000104@fillmore-labs.com> Date: Tue, 30 Mar 2004 00:54:02 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: Michael Nottebrock 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> <40689343.4080602@fillmore-labs.com> <4068A0AF.2090807@gmx.net> In-Reply-To: <4068A0AF.2090807@gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: "Jacques A. Vidrine" cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 22:54:07 -0000 Michael Nottebrock wrote: > > 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'. > > Why? I mean, seriously, if I choose to install portaudit and portaudit's > presence prevents me from installing ports that's okay, but enforcing > this even when I _don't_ want to use portaudit it's not, IMHO. I guess you mix up things here. We are talking about semantics. Marking a port FORBIDDEN if it has a security vulnerability has nothing to do with portaudit. If you have an current ports tree and update your ports every time a new version is available, you don't need portaudit. > Actually, > I always thought portaudit was all about providing a way of making ports > off-limits _without_ CVS being involved. Exactly that is the point: you can mark ports FORBIDDEN retroactively, which means versions that are now longer current, or on systems where there is no (current) ports tree (like on release CDs), or the ports are not updated immediately. > So I agree with Jacques here, > portaudit and FORBIDDEN should remain separate. Thats a question of sematics. It makes absolutely no sense to add a package to the portaudit database when you won't mark the port as FORBIDDEN. The message is `do not install this port', and I hope to get support for portaudit into sysinstall to prevent users with release CDs to install vulnerable ports in the first place. Currently there is no such thing as `It may be ok to use this port if you are careful', if you deem such a feature useful I will look into implementing such a feature. -Oliver From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 15:41:30 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7811416A4CE; Mon, 29 Mar 2004 15:41:30 -0800 (PST) Received: from postman.arcor.de (postman2.arcor-online.net [151.189.0.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1E0E43D39; Mon, 29 Mar 2004 15:41:29 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i2TNfSko017738 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 30 Mar 2004 01:41:28 +0200 (MEST) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1B86Ni-000OZR-7v; Tue, 30 Mar 2004 01:41:26 +0200 Message-ID: <4068B425.1070607@fillmore-labs.com> Date: Tue, 30 Mar 2004 01:41:25 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: "Jacques A. Vidrine" 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> <40689343.4080602@fillmore-labs.com> <20040329224011.GA94303@madman.celabo.org> In-Reply-To: <20040329224011.GA94303@madman.celabo.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 23:41:30 -0000 Jacques A. Vidrine wrote: > Speaking of pkg_add, I was thinking it might make sense to add hooks > to these utilities, either in the form of loading dynamic objects or > just invoking shell scripts. It seems that knu@ would be able to > use these for portupgrade, we could use them for portaudit and VuXML > related items, and power users could use them to invent their own > local uses. But, that's a discussion for ports@ I guess. Hooks would be nice, but I guess we should have something in the base, or at least let sysinstall install it by default before adding other packages. > Personally, I was quite pleased with the way that you have it set up: > if users install portaudit, then they will be warned daily about ports > that they have installed; and attempting to build the port results in > much the same thing as FORBIDDEN. > > (I guess I could have some misunderstanding, though.) No, that is precisely the idea: marking a port in portaudit results in much the same thing as FORBIDDEN, so the criteria to add a package to the portaudit database is excatly the same as marking a port as FORBIDDEN because of security reasons. > Without portaudit, we have the current situation. The only ports > marked FORBIDDEN are those where someone believed that problems are > serious enough to mark it so. This should be the same with portaudit, even on past revisions of the ports: The only port added in the portaudit database should be those where someone believed that problems are serious enough to mark it so. To cite portaudit(1): "If you have a vulnerable package installed, you are advised to update or deinstall it immediately." > I often mail folks when I enter their port into VuXML. I intend to > automate this nagging, but just haven't gotten around to it yet. What is the point in not marking those port as FORBIDDEN? It is easy to remove (so you don't romp over port maintainers, like just committing the fix, which might be done differently), gives maintainers time to analyze the issue without piecing together a quick fix and prevents the vulnerable version from being installed. In my eyes this benefits maintainers (who have to fix these issues anyways, but have more room to do so) as well as users (which normally do not want to use vulnerable ports, especially since exploits get more popular every day), or do I make a mistake here? >>Since you are the FreeBSD Security Officer, you are the ultimate authority >>what issues are serious. > > I'm just a guy. The Security Team are just more guys (but very > helpful and clueful ones--- thanks guys!!). We want and need > coordination with the ports maintainers: they (should) have a level > of expertise with their particular applications that we simply cannot > have for the 10,000+ ports. I totally agree, although this doesn't conflict with the sentence above. > Not to mention, ports maintainers can be touchy. As can we all :-) I can understand this in the case of functional changes to the port, things that could have been done differently. A FORBIDDEN line could only be removed, whether you like it or not. And if the port maintainer believes that the vulnerability doesn't exist, (s)he could remove the entry from the VuXML file, or set the severity to minor, so backing out from a FORBIDDEN is easy too. Of course I don't like to maintain a vulnerable port... ;P >>It seems like there are criteria that have consequences (marking >>a port FORBIDDEN or not), please note this somewhere in the VuXML >>document. > > I'd like to take a step before committing myself (and any would-be > VuXML contributor) into assigning a severity to every issue. If > there is rough consensus from the ports community (committers and > maintainers) that any documented security issue is grounds enough to > mark a port FORBIDDEN, then we'll follow the policy that (entry in > VuXML document) == (port must be marked FORBIDDEN). > > This seems to be your stance, and I do not think it is unreasonable. > Although I made the comment earlier that I don't share the opinion, it > is nonetheless attractive because it is simple :-) I can live with both. Either VuXML contains only entries that are so serious that a port should be marked FORBIDDEN, or it contains additional entries that are not of this importance and are marked as such. The decision how severe an issue is has already be made with every commit to the VuXML document (by marking the affected ports as FORBIDDEN or not), it is only not documented. This is just a question of a clearly stated policy, not about assigning a severity - that is already done. -Oliver From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 16:00:07 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3336616A4CE; Mon, 29 Mar 2004 16:00:07 -0800 (PST) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8AE443D39; Mon, 29 Mar 2004 16:00:06 -0800 (PST) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id D0B8D167588; Tue, 30 Mar 2004 02:00:05 +0200 (CEST) Received: from gmx.net (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i2U004u7001363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2004 02:00:05 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) Message-ID: <4068B881.4010304@gmx.net> Date: Tue, 30 Mar 2004 02:00:01 +0200 From: Michael Nottebrock User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, de-de MIME-Version: 1.0 To: Oliver Eikemeier 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> <40689343.4080602@fillmore-labs.com> <4068A0AF.2090807@gmx.net> <4068A90A.7000104@fillmore-labs.com> In-Reply-To: <4068A90A.7000104@fillmore-labs.com> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig594423963BBD96DDBD6F14E9" X-Virus-Scanned: by amavisd-new cc: "Jacques A. Vidrine" cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 00:00:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig594423963BBD96DDBD6F14E9 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Oliver Eikemeier wrote: > Thats a question of sematics. It makes absolutely no sense to add a > package to > the portaudit database when you won't mark the port as FORBIDDEN. To me it makes no sense anymore to mark ports FORBIDDEN for security reasons at all - portaudit uses a centralized source of information, it is much more efficient than cvsup, as you mentioned it's smarter with regard to old versions and it does automated checks via periodic. In short, bye-bye FORBIDDEN, hello portaudit. > The > message > is `do not install this port', and I hope to get support for portaudit into > sysinstall to prevent users with release CDs to install vulnerable ports in > the first place. Currently there is no such thing as `It may be ok to > use this > port if you are careful', if you deem such a feature useful I will look > into > implementing such a feature. I'd deem such a feature quite useful indeed. Actually, the decisionmaking about what is too serious to ignore and what is not could be handed back to the system administrator this way: If VuXML would provide a fine-grained classification of security issues (not by severity, but by type: privilige escalation (incl. root/excl. root), local/remote denial-of-service, buffer-overflow-but-no-exploit-known, etc, etc), users could customize portaudit to forbid access to packages or just warn about them from a set of rules (which would ideally also allow to make exceptions by portname and other criteria - I realise that's quite a wishlist, but since you asked... ;-)). The current behaviour could be provided as default. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --------------enig594423963BBD96DDBD6F14E9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows 2000) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAaLiEXhc68WspdLARAsV8AJsHcXgr3HBHJLCL1YtUHT0Ct8Lc+wCeO+zw vwbyi3/3j+Pmg1NG5avbUWg= =Ne3G -----END PGP SIGNATURE----- --------------enig594423963BBD96DDBD6F14E9-- From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 17:25:11 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9077F16A4CF; Mon, 29 Mar 2004 17:25:11 -0800 (PST) Received: from postman.arcor.de (postman4.arcor-online.net [151.189.0.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 056AE43D5A; Mon, 29 Mar 2004 17:25:11 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i2U1P4D2010052 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 30 Mar 2004 03:25:09 +0200 (MEST) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1B87zx-000P4B-RV; Tue, 30 Mar 2004 03:25:01 +0200 Message-ID: <4068CC6D.10400@fillmore-labs.com> Date: Tue, 30 Mar 2004 03:25:01 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: "Jacques A. Vidrine" 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> <40689343.4080602@fillmore-labs.com> <20040329224011.GA94303@madman.celabo.org> In-Reply-To: <20040329224011.GA94303@madman.celabo.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 01:25:11 -0000 Jacques A. Vidrine wrote: > [...] > By all means, there's certainly nothing wrong with hosting your > project on your own page. But Oliver, when one visits the URLs > that you've posted, one is presented with content that, in the vast > majority of cases, was not authored by you and has little association > with `portaudit'. [...] I'm sorry, it has never been my intention to assert authorship of the content. I've added the following disclaimer to all pages: The data contained on this page is derived for the VuXML document, please refer to the the original document for copyright information. The author of portaudit makes no claim of authorship or ownership of any of the information contained herein. I'm not sure about the association though. Does this meet your needs, or do you have a suggestion for a different text? -Oliver From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 17:35:15 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 244E716A4CE; Mon, 29 Mar 2004 17:35:15 -0800 (PST) Received: from postman.arcor.de (postman4.arcor-online.net [151.189.0.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8570643D5A; Mon, 29 Mar 2004 17:35:14 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i2U1ZCD2010658 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 30 Mar 2004 03:35:13 +0200 (MEST) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1B889m-000P4w-6z; Tue, 30 Mar 2004 03:35:10 +0200 Message-ID: <4068CECD.8070300@fillmore-labs.com> Date: Tue, 30 Mar 2004 03:35:09 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: "Jacques A. Vidrine" 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> In-Reply-To: <20040329201926.GA88529@madman.celabo.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 01:35:15 -0000 Jacques A. Vidrine wrote: >>>>>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 :-) While we are at it: port www/squid24 is listed in 705e003a-7f36-11d8-9645-0020ed76ef5a. Is this serious? Isn't it? Who should decide? From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 19:16:07 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 841BA16A4CE for ; Mon, 29 Mar 2004 19:16:07 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 435AB43D1D for ; Mon, 29 Mar 2004 19:16:07 -0800 (PST) (envelope-from nectar@celabo.org) 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 CC03A5485D; Mon, 29 Mar 2004 21:16:06 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 5F1676D465; Mon, 29 Mar 2004 21:16:06 -0600 (CST) Date: Mon, 29 Mar 2004 21:16:06 -0600 From: "Jacques A. Vidrine" To: Oliver Eikemeier Message-ID: <20040330031606.GA5998@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Oliver Eikemeier , FreeBSD Security 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> <4068CECD.8070300@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4068CECD.8070300@fillmore-labs.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 03:16:07 -0000 On Tue, Mar 30, 2004 at 03:35:09AM +0200, Oliver Eikemeier wrote: > While we are at it: port www/squid24 is listed in > 705e003a-7f36-11d8-9645-0020ed76ef5a. > > Is this serious? Isn't it? Who should decide? It's a good example for this topic. Let's have a look. squid ACL bypass due to URL decoding bug Affected packages squid < squid-2.5.5 Details VuXML ID 705e003a-7f36-11d8-9645-0020ed76ef5a Discovery 2004-02-29 Entry 2004-03-26 From the Squid advisory: Squid versions 2.5.STABLE4 and earlier contain a bug in the "%xx" URL decoding function. It may insert a NUL character into decoded URLs, which may allow users to bypass url_regex ACLs. References CVE Name CVE-2004-0189 URL http://www.squid-cache.org/Advisories/SQUID-2004_1.txt Now I did not mark the squid port FORBIDDEN when I added this, because I do not believe that there is impending danger to any squid user. I arrived at this conclusion after considering: (a) Only users who use Squid's ACLs to block certain URLs could possibly be affected. (b) For those users who are affected, the impact is quite mild. Perhaps IT is trying to stop users from view pr0n, or from visiting job sites, or some such. By stretching the imagination, perhaps there might be some type of service provider out there somewhere using this feature to control level of service. For example, a wireless provider that lets anyone use their infrastructure to view ``local'' content but needs a service contract to reach the Internet. This scenario (using Squid for this purpose) doesn't seem likely at all. So, I do not think this port needs to be marked FORBIDDEN for all FreeBSD users. However, I *do* think that it is important to document this issue, and to let our community know about it. Thus, it is entered into the VuXML document. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 19:38:12 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 635F216A4CE for ; Mon, 29 Mar 2004 19:38:12 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1462F43D2D for ; Mon, 29 Mar 2004 19:38:12 -0800 (PST) (envelope-from nectar@celabo.org) 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 900175485D; Mon, 29 Mar 2004 21:38:11 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 197266D465; Mon, 29 Mar 2004 21:38:11 -0600 (CST) Date: Mon, 29 Mar 2004 21:38:11 -0600 From: "Jacques A. Vidrine" To: Oliver Eikemeier Message-ID: <20040330033810.GB5998@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Oliver Eikemeier , FreeBSD Security 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> <40689343.4080602@fillmore-labs.com> <20040329224011.GA94303@madman.celabo.org> <4068CC6D.10400@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4068CC6D.10400@fillmore-labs.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 03:38:12 -0000 On Tue, Mar 30, 2004 at 03:25:01AM +0200, Oliver Eikemeier wrote: > Jacques A. Vidrine wrote: > > >[...] > >By all means, there's certainly nothing wrong with hosting your > >project on your own page. But Oliver, when one visits the URLs > >that you've posted, one is presented with content that, in the vast > >majority of cases, was not authored by you and has little association > >with `portaudit'. [...] > > I'm sorry, it has never been my intention to assert authorship of > the content. Oh, I didn't think that for a moment. I recall that earlier you were quite fixated on the FreeBSD license, and diligently sought what permissions/postings might be needed [1]. I requested that when you refer to a VuXML entry, particularly in the context of the FreeBSD Project--- commit logs, mailing lists, whatever--- to please use the vuxml.freebsd.org URL. You said that you preferred to use your personal web page URL on the basis that it is the project page for portaudit. OK, but portaudit != VuXML. Please, refer to the portaudit project page for portaudit. But refer to the VuXML pages for VuXML entries and information on VuXML. By the way, if one wishes to point to the portaudit tool, what URL gives the best description? Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org [1] To recap for others: The content is the FreeBSD Documentation License... one need only reproduce the copyright statement somewhere in the rendered version. For example, at http://vuxml.freebsd.org/, I've taken the approach of putting this at the bottom of each page: ``Copyright © 2003, 2004 Jacques Vidrine and contributors. Please see the source of this document for full copyright information.'' The comments of the document contain the license in its entirety. Plenty of other approaches are suitable. The BSD license is one of the friendliest in the world, letting you do almost anything you want with the covered material, short of claiming your dog wrote it or suing the author because it contains egregious typos. From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 20:56:48 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58EE516A4CE for ; Mon, 29 Mar 2004 20:56:48 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id D00D943D2D for ; Mon, 29 Mar 2004 20:56:47 -0800 (PST) (envelope-from nectar@celabo.org) 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 2F3AC5482B; Mon, 29 Mar 2004 22:56:47 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id B7A956D465; Mon, 29 Mar 2004 22:56:46 -0600 (CST) Date: Mon, 29 Mar 2004 22:56:46 -0600 From: "Jacques A. Vidrine" To: Michael Nottebrock Message-ID: <20040330045646.GD5998@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Michael Nottebrock , Oliver Eikemeier , FreeBSD Security 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> <40689343.4080602@fillmore-labs.com> <4068A0AF.2090807@gmx.net> <4068A90A.7000104@fillmore-labs.com> <4068B881.4010304@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4068B881.4010304@gmx.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: FreeBSD Security cc: Oliver Eikemeier Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 04:56:48 -0000 On Tue, Mar 30, 2004 at 02:00:01AM +0200, Michael Nottebrock wrote: > If VuXML would provide a fine-grained > classification of security issues (not by severity, but by type: privilige > escalation (incl. root/excl. root), local/remote denial-of-service, > buffer-overflow-but-no-exploit-known, etc, etc), users could customize > portaudit to forbid access to packages or just warn about them from a set > of rules (which would ideally also allow to make exceptions by portname and > other criteria - I realise that's quite a wishlist, but since you asked... > ;-)). It so happens that in the past month or so there has been quite a discussion on a closed vendor security list (mostly large Linux distros + some UNIX vendors) regarding severity rating systems. It's really hard, and it's really subjective. CVE does not assign severity, largely because they do not feel that it is part of their role. Attempts to create systems such as you describe (types of vulnerabilities) have bogged down: some of the better thought out proposals result in 4-6 dimensions. As you probably are aware, it can take a lot of time to research and accurately describe a single vulnerability. I don't know what other's standards are, but before I add something to VuXML, I: (a) track down the original report of the vulnerability (b) confirm it does or does not affect our port by source code review (I skipped this once and got burned) (c) determine what versions of the port are affected (d) get an idea of the impact in order to focus the description of the vulnerability (e) collect as many high quality references to the vulnerability as possible This is about as much work as I'm willing to do :-) Additionally classifying the bug along four to six dimensions could easily double the time to document it. My impression from the discussions I mentioned above is that the (full time, paid) security teams of many vendors are not prepared to invest that kind of time for every reported issue. We do not have a full time, paid team (or AFAIK even a single individual) to do this, either. On the other hand, many use simple high/medium/low ratings, but are dissatisfied by them due to their necessarily gross misrepresentation of most bugs :-) e.g. Some folks will skip fixes because they were rated `low', when in fact *those folks* really need the fix (due to local configuration or what have you). The only reasonable option for the security conscious (IMHO), is to avoid applications with *any* reported security issues until one has read and understood that issue. This is pretty close to what Oliver's portaudit does (I think). Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 20:56:50 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F0F016A4CE for ; Mon, 29 Mar 2004 20:56:50 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2006043D2F for ; Mon, 29 Mar 2004 20:56:50 -0800 (PST) (envelope-from nectar@celabo.org) 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 B9C4754840; Mon, 29 Mar 2004 22:56:49 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 803D16D467; Mon, 29 Mar 2004 22:56:49 -0600 (CST) Date: Mon, 29 Mar 2004 22:56:49 -0600 From: "Jacques A. Vidrine" To: Oliver Eikemeier Message-ID: <20040330045649.GE5998@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Oliver Eikemeier , FreeBSD Security 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> <40689343.4080602@fillmore-labs.com> <20040329224011.GA94303@madman.celabo.org> <4068B425.1070607@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4068B425.1070607@fillmore-labs.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 04:56:50 -0000 On Tue, Mar 30, 2004 at 01:41:25AM +0200, Oliver Eikemeier wrote: > Hooks would be nice, but I guess we should have something in the base, > or at least let sysinstall install it by default before adding other > packages. *nod* Hooks fulfill the role either way, but have the advantage of allowing alternatives. > >Personally, I was quite pleased with the way that you have it set up: > >if users install portaudit, then they will be warned daily about ports > >that they have installed; and attempting to build the port results in > >much the same thing as FORBIDDEN. > > > >(I guess I could have some misunderstanding, though.) > > No, that is precisely the idea: marking a port in portaudit results in > much the same thing as FORBIDDEN, so the criteria to add a package to > the portaudit database is excatly the same as marking a port as > FORBIDDEN because of security reasons. That doesn't logically follow. The criteria for marking a port FORBIDDEN is (currently) quite different than the criteria for entering an issue into the FreeBSD VuXML document. I didn't in particular create VuXML to replace FORBIDDEN--- although I don't object if that is what folks want. > >Without portaudit, we have the current situation. The only ports > >marked FORBIDDEN are those where someone believed that problems are > >serious enough to mark it so. > > This should be the same with portaudit, even on past revisions of the > ports: The only port added in the portaudit database should be those > where someone believed that problems are serious enough to mark it so. > > To cite portaudit(1): > > "If you have a vulnerable package installed, you are advised to update or > deinstall it immediately." OK, I think I understand your viewpoint. I believe you are asking for some connection to be made between VuXML and FORBIDDEN. But portaudit doesn't *in fact* have anything to do with that policy. portaudit is *in fact* a tool for implementing an alternate policy. In other words, you can't equate portaudit's policy with the FreeBSD Ports Collection's FORBIDDEN policy. That's begging the question. > >I often mail folks when I enter their port into VuXML. I intend to > >automate this nagging, but just haven't gotten around to it yet. > > What is the point in not marking those port as FORBIDDEN? It is easy to > remove (so you don't romp over port maintainers, like just committing the > fix, which might be done differently), gives maintainers time to analyze > the issue without piecing together a quick fix and prevents the vulnerable > version from being installed. In my eyes this benefits maintainers (who have > to fix these issues anyways, but have more room to do so) as well as users > (which normally do not want to use vulnerable ports, especially since > exploits get more popular every day), or do I make a mistake here? What are the advantages of this approach versus automated nagging, and prudently applying FORBIDDEN? I've already stated what I think the disadvantages are. But, of course I'm ready to hear more. [...] > >I'd like to take a step before committing myself (and any would-be > >VuXML contributor) into assigning a severity to every issue. If > >there is rough consensus from the ports community (committers and > >maintainers) that any documented security issue is grounds enough to > >mark a port FORBIDDEN, then we'll follow the policy that (entry in > >VuXML document) == (port must be marked FORBIDDEN). > > > >This seems to be your stance, and I do not think it is unreasonable. > >Although I made the comment earlier that I don't share the opinion, it > >is nonetheless attractive because it is simple :-) > > I can live with both. Either VuXML contains only entries that are so > serious that a port should be marked FORBIDDEN, or it contains additional > entries that are not of this importance and are marked as such. I guess we are at contrapoint. I specifically do not wish to constrain VuXML entries to only those which are ``serious'' (by some widely-accepted definition of `serious'). And I specifically want to avoid assigning severity to entries. See my other recent posting for reasons why. > The decision how severe an issue is has already be made with every commit > to the VuXML document (by marking the affected ports as FORBIDDEN or not), > it is only not documented. This is just a question of a clearly stated > policy, not about assigning a severity - that is already done. Well, you do have a point. So, I'm happy with this approach, but also willing to be convinced that other approaches are better. :-) Just in case I haven't stated it enough times yet to be clear, I'll do it once more: If the community wants all ports that become listed in the VuXML document to be marked FORBIDDEN--- well, we can arrange that. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Mon Mar 29 22:25:46 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D48D16A4CE; Mon, 29 Mar 2004 22:25:46 -0800 (PST) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id C01AD43D41; Mon, 29 Mar 2004 22:25:45 -0800 (PST) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id D33F1167588; Tue, 30 Mar 2004 08:25:44 +0200 (CEST) Received: from gmx.net (kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i2U6PhG2007077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2004 08:25:43 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) Message-ID: <406912E7.4040806@gmx.net> Date: Tue, 30 Mar 2004 08:25:43 +0200 From: Michael Nottebrock User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, de-de MIME-Version: 1.0 To: "Jacques A. Vidrine" 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> <40689343.4080602@fillmore-labs.com> <4068A0AF.2090807@gmx.net> <4068A90A.7000104@fillmore-labs.com> <4068B881.4010304@gmx.net> <20040330045646.GD5998@madman.celabo.org> In-Reply-To: <20040330045646.GD5998@madman.celabo.org> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF31C483BAD65430945D97BEB" X-Virus-Scanned: by amavisd-new cc: FreeBSD Security cc: Oliver Eikemeier Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 06:25:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF31C483BAD65430945D97BEB Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jacques A. Vidrine wrote: > It so happens that in the past month or so there has been quite a > discussion on a closed vendor security list (mostly large Linux > distros + some UNIX vendors) regarding severity rating systems. > It's really hard, and it's really subjective. CVE does not assign > severity, largely because they do not feel that it is part of their > role. Attempts to create systems such as you describe (types of > vulnerabilities) have bogged down: some of the better thought out > proposals result in 4-6 dimensions. Okay, that's quite impossible then. > The only reasonable option for the security conscious (IMHO), is to > avoid applications with *any* reported security issues until one has > read and understood that issue. This is pretty close to what Oliver's > portaudit does (I think). Right, and I have no problem with that (I _like_ portaudit :-)). However, it seems to me that marking ports FORBIDDEN for security reasons is more or less obsoleted (and made redundant) by portaudit/VuXML and committers having to hand-scan VuXML for updates and mark ports FORBIDDEN by hand just seems like duplicated (and error-prone) work... so maybe it's time to to away with marking ports FORBIDDEN for security reasons completely? Also, what eik says about integrating portaudit into sysinstall (does this imply moving portaudit into the base-system at some point?) sounds very good to me, but I still don't like security-by-default schemes which can't be disabled by flipping a switch. FORBIDDEN ports are an example for this, forcing users to hand-edit a port Makefile in order to make it buildable (especially when the security issue is really minor or I'm not even affected) is just a tad too BOFH-ish for my taste. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --------------enigF31C483BAD65430945D97BEB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows 2000) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAaRLnXhc68WspdLARAgwJAKCQ2fTsCFuPaY3uvBXdFNgyac5KsgCff7FE mstC+3p3nc1ugfrm8If3ymc= =gkuU -----END PGP SIGNATURE----- --------------enigF31C483BAD65430945D97BEB-- From owner-freebsd-security@FreeBSD.ORG Tue Mar 30 01:13:18 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF9A816A4CE; Tue, 30 Mar 2004 01:13:18 -0800 (PST) Received: from postman.arcor.de (newsread1.arcor-online.net [151.189.0.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11FC543D45; Tue, 30 Mar 2004 01:13:18 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i2U9DFck004454 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 30 Mar 2004 11:13:16 +0200 (MEST) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1B8FJ3-000PmM-4h; Tue, 30 Mar 2004 11:13:13 +0200 Message-ID: <40693A28.9000502@fillmore-labs.com> Date: Tue, 30 Mar 2004 11:13:12 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: Michael Nottebrock 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> <40689343.4080602@fillmore-labs.com> <4068A0AF.2090807@gmx.net> <4068A90A.7000104@fillmore-labs.com> <4068B881.4010304@gmx.net> <20040330045646.GD5998@madman.celabo.org> <406912E7.4040806@gmx.net> In-Reply-To: <406912E7.4040806@gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: "Jacques A. Vidrine" cc: FreeBSD Ports Management Team cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 09:13:19 -0000 Michael Nottebrock wrote: > [...] > However, it seems to me that marking ports FORBIDDEN for security > reasons is more or less obsoleted (and made redundant) by > portaudit/VuXML and committers having to hand-scan VuXML for updates and > mark ports FORBIDDEN by hand just seems like duplicated (and > error-prone) work... so maybe it's time to to away with marking ports > FORBIDDEN for security reasons completely? I think portmgr@ is the authority here. CC'ed. > Also, what eik says about integrating portaudit into sysinstall (does > this imply moving portaudit into the base-system at some point?) sounds > very good to me, but I still don't like security-by-default schemes > which can't be disabled by flipping a switch. FORBIDDEN ports are an > example for this, forcing users to hand-edit a port Makefile in order to > make it buildable (especially when the security issue is really minor or > I'm not even affected) is just a tad too BOFH-ish for my taste. Just build the port with NO_IGNORE=yes. To disable portaudit use DISABLE_VULNERABILITIES=yes. A common namespace would be a good thing here, I guess. There is currently no way to turn of warnings selectively (like `read and understood'), I don't know if this would be useful. From owner-freebsd-security@FreeBSD.ORG Tue Mar 30 07:43:02 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 263A816A4CE for ; Tue, 30 Mar 2004 07:43:02 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD97243D49 for ; Tue, 30 Mar 2004 07:43:01 -0800 (PST) (envelope-from nectar@celabo.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id 740225487E; Tue, 30 Mar 2004 09:43:01 -0600 (CST) 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 83042-06; Tue, 30 Mar 2004 09:42:50 -0600 (CST) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 71C9554893; Tue, 30 Mar 2004 09:41:57 -0600 (CST) Received: by lum.celabo.org (Postfix, from userid 501) id AC90F18336D; Tue, 30 Mar 2004 08:24:16 -0600 (CST) Date: Tue, 30 Mar 2004 08:24:16 -0600 From: "Jacques A. Vidrine" To: Michael Nottebrock Message-ID: <20040330142416.GJ10949@lum.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Michael Nottebrock , Oliver Eikemeier , FreeBSD Security References: <40686785.7020002@fillmore-labs.com> <20040329185347.GB87233@madman.celabo.org> <40687E18.9060907@fillmore-labs.com> <20040329201926.GA88529@madman.celabo.org> <40689343.4080602@fillmore-labs.com> <4068A0AF.2090807@gmx.net> <4068A90A.7000104@fillmore-labs.com> <4068B881.4010304@gmx.net> <20040330045646.GD5998@madman.celabo.org> <406912E7.4040806@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406912E7.4040806@gmx.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: FreeBSD Security cc: Oliver Eikemeier Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 15:43:02 -0000 On Tue, Mar 30, 2004 at 08:25:43AM +0200, Michael Nottebrock wrote: > Right, and I have no problem with that (I _like_ portaudit :-)). However, > it seems to me that marking ports FORBIDDEN for security reasons is more or > less obsoleted (and made redundant) by portaudit/VuXML and committers > having to hand-scan VuXML for updates and mark ports FORBIDDEN by hand just > seems like duplicated (and error-prone) work... so maybe it's time to to > away with marking ports FORBIDDEN for security reasons completely? Maybe :-) > Also, what eik says about integrating portaudit into sysinstall (does this > imply moving portaudit into the base-system at some point?) sounds very > good to me, but I still don't like security-by-default schemes which can't > be disabled by flipping a switch. FORBIDDEN ports are an example for this, > forcing users to hand-edit a port Makefile in order to make it buildable > (especially when the security issue is really minor or I'm not even > affected) is just a tad too BOFH-ish for my taste. Well, a reason I mentioned `hooks' to Oliver is because I have my own unfinished scheme for managing this issue. It takes a different approach than portaudit, that I think you'd like. But I don't want to say more because it is vaporware until release :-) Basically, any attempt to integrate such vulnerability checking into pkg_* tools or bsd.port.mk needs to be done so that tools can plug-in. In that fashion, users have a choice of security policy. The commit of a `Vulnerability Check' to bsd.port.mk happened under my radar, so I didn't comment on it at the time. It may or may not be sufficient for hooks as it is now. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Tue Mar 30 07:46:37 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3668416A4CE; Tue, 30 Mar 2004 07:46:37 -0800 (PST) Received: from postman.arcor.de (postman4.arcor-online.net [151.189.0.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0C5943D48; Tue, 30 Mar 2004 07:46:36 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i2UFkYD2014261 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 30 Mar 2004 17:46:35 +0200 (MEST) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1B8KrZ-0000KJ-3I; Tue, 30 Mar 2004 17:09:13 +0200 Message-ID: <40698D98.8010304@fillmore-labs.com> Date: Tue, 30 Mar 2004 17:09:12 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: "Jacques A. Vidrine" 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> <40689343.4080602@fillmore-labs.com> <20040329224011.GA94303@madman.celabo.org> <4068B425.1070607@fillmore-labs.com> <20040330045649.GE5998@madman.celabo.org> In-Reply-To: <20040330045649.GE5998@madman.celabo.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 15:46:37 -0000 Jacques A. Vidrine wrote: >>>Personally, I was quite pleased with the way that you have it set up: >>>if users install portaudit, then they will be warned daily about ports >>>that they have installed; and attempting to build the port results in >>>much the same thing as FORBIDDEN. >>> >>>(I guess I could have some misunderstanding, though.) >> >>No, that is precisely the idea: marking a port in portaudit results in >>much the same thing as FORBIDDEN, so the criteria to add a package to >>the portaudit database is excatly the same as marking a port as >>FORBIDDEN because of security reasons. > > That doesn't logically follow. The criteria for marking a port > FORBIDDEN is (currently) quite different than the criteria for > entering an issue into the FreeBSD VuXML document. I didn't in > particular create VuXML to replace FORBIDDEN--- although I don't > object if that is what folks want. The problem here is that the portaudit database is generated from the VuXML document, and the criteria to add a package to the portaudit database *is* the same as marking a port as FORBIDDEN, so I have the problem of synchronizing the VuXML document and the portaudit database here. I can't have a different policy for portaudit, since the results are the same. Basically portaudit can replace FORBIDDEN, adding a retroactive view. There is no problem to add an extra flag if a knowledgeable user wants to have extra security, but this can't be the default. >>>Without portaudit, we have the current situation. The only ports >>>marked FORBIDDEN are those where someone believed that problems are >>>serious enough to mark it so. >> >>This should be the same with portaudit, even on past revisions of the >>ports: The only port added in the portaudit database should be those >>where someone believed that problems are serious enough to mark it so. >> >>To cite portaudit(1): >> >>"If you have a vulnerable package installed, you are advised to update or >>deinstall it immediately." > > OK, I think I understand your viewpoint. I believe you are asking for > some connection to be made between VuXML and FORBIDDEN. But portaudit > doesn't *in fact* have anything to do with that policy. portaudit is > *in fact* a tool for implementing an alternate policy. It is not. It hinders you to install vulnerable ports, like FORBIDDEN does, and notifies you retroactively if a port that should have been FORBIDDEN is installed. What should be the alternate policy there? > In other words, you can't equate portaudit's policy with the FreeBSD > Ports Collection's FORBIDDEN policy. That's begging the question. Why can't I? I can't do this for the VuXML policy, but I can for portaudit. The problem here is that VuXML has a policy that makes it hard for me to integrate into portaudit. > [...] > > I specifically do not wish to constrain VuXML entries to only > those which are ``serious'' (by some widely-accepted definition of > `serious'). > > And I specifically want to avoid assigning severity to entries. See > my other recent posting for reasons why. I guess then I have do do a canditate system, where new vulnerabilities are only added to the portaudit database when they are verified as being serious. This means going back to a seperate portaudit database, which is unfortunate. I might later implement a notification system for issues with lesser importance, but I see no point in using portaudit to hinder users to install a certain port if an issue is not deemed to be severe enough to mark the port as FORBIDDEN. >>The decision how severe an issue is has already be made with every commit >>to the VuXML document (by marking the affected ports as FORBIDDEN or not), >>it is only not documented. This is just a question of a clearly stated >>policy, not about assigning a severity - that is already done. > > Well, you do have a point. So, I'm happy with this approach, but also > willing to be convinced that other approaches are better. :-) > > Just in case I haven't stated it enough times yet to be clear, I'll do > it once more: > If the community wants all ports that become listed in the VuXML > document to be marked FORBIDDEN--- well, we can arrange that. It is your document, you can set the policy. If you want to make it usable for portaudit, give me either a severity tag with a defined policy whether the port has to be marked as FORBIDDEN or nor, or add only serious entries. If certain vulnerabilities are not serious enough to hinder people to install the port, I see no reason for using portaudit to do so. -Oliver From owner-freebsd-security@FreeBSD.ORG Tue Mar 30 08:06:43 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 038DB16A4CE; Tue, 30 Mar 2004 08:06:43 -0800 (PST) Received: from postman.arcor.de (postman2.arcor-online.net [151.189.0.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C87A43D45; Tue, 30 Mar 2004 08:06:42 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i2UG6dko004230 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 30 Mar 2004 18:06:41 +0200 (MEST) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.31; FreeBSD) id 1B8Ll3-00026R-Ux; Tue, 30 Mar 2004 18:06:39 +0200 Message-ID: <40699B09.5020107@fillmore-labs.com> Date: Tue, 30 Mar 2004 18:06:33 +0200 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <40686785.7020002@fillmore-labs.com> <20040329185347.GB87233@madman.celabo.org> <40687E18.9060907@fillmore-labs.com> <20040329201926.GA88529@madman.celabo.org> <40689343.4080602@fillmore-labs.com> <4068A0AF.2090807@gmx.net> <4068A90A.7000104@fillmore-labs.com> <4068B881.4010304@gmx.net> <20040330045646.GD5998@madman.celabo.org> <406912E7.4040806@gmx.net> <20040330142416.GJ10949@lum.celabo.org> In-Reply-To: <20040330142416.GJ10949@lum.celabo.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 16:06:43 -0000 Jacques A. Vidrine wrote: > [...] > In that fashion, users have a choice of security policy. Could you elaborate a bit what you mean with `choice of security policy'? Which different security policies are there to choose from? -Oliver From owner-freebsd-security@FreeBSD.ORG Tue Mar 30 08:23:41 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 527F816A4CE; Tue, 30 Mar 2004 08:23:41 -0800 (PST) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD02343D1D; Tue, 30 Mar 2004 08:23:40 -0800 (PST) (envelope-from marcus@marcuscom.com) Received: from [10.2.1.4] (vpn-client-4.marcuscom.com [10.2.1.4]) i2UGMIEP019449; Tue, 30 Mar 2004 11:22:18 -0500 (EST) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Oliver Eikemeier In-Reply-To: <40693A28.9000502@fillmore-labs.com> 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> <40689343.4080602@fillmore-labs.com> <4068A0AF.2090807@gmx.net> <4068A90A.7000104@fillmore-labs.com> <4068B881.4010304@gmx.net> <20040330045646.GD5998@madman.celabo.org> <406912E7.4040806@gmx.net> <40693A28.9000502@fillmore-labs.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-29G4XKOJ18SnWRA5HVp5" Organization: MarcusCom, Inc. Message-Id: <1080663846.792.3.camel@gyros> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 30 Mar 2004 11:24:06 -0500 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on creme-brulee.marcuscom.com X-Mailman-Approved-At: Wed, 31 Mar 2004 01:46:12 -0800 cc: "Jacques A. Vidrine" cc: FreeBSD Ports Management Team cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 16:23:41 -0000 --=-29G4XKOJ18SnWRA5HVp5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-03-30 at 04:13, Oliver Eikemeier wrote: > Michael Nottebrock wrote: >=20 > > [...] > > However, it seems to me that marking ports FORBIDDEN for security=20 > > reasons is more or less obsoleted (and made redundant) by=20 > > portaudit/VuXML and committers having to hand-scan VuXML for updates an= d=20 > > mark ports FORBIDDEN by hand just seems like duplicated (and=20 > > error-prone) work... so maybe it's time to to away with marking ports=20 > > FORBIDDEN for security reasons completely? >=20 > I think portmgr@ is the authority here. CC'ed. Since VuXML is still optional, and newbies will not be likely to have it, I believe we still should be marking ports FORBIDDEN for security reasons. Better to wear a belt and suspenders. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-29G4XKOJ18SnWRA5HVp5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAaZ8mb2iPiv4Uz4cRAumnAKCbFwboM3uHaJKt6yjdYI2GIHpChQCgrMop R4QPzfAkPhlhNEf6PJf4QZE= =4amf -----END PGP SIGNATURE----- --=-29G4XKOJ18SnWRA5HVp5-- From owner-freebsd-security@FreeBSD.ORG Wed Mar 31 08:53:02 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6421016A4CE for ; Wed, 31 Mar 2004 08:53:02 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1567643D2D for ; Wed, 31 Mar 2004 08:53:02 -0800 (PST) (envelope-from nectar@celabo.org) 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 A53CB5487F; Wed, 31 Mar 2004 10:53:01 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 53AF16D465; Wed, 31 Mar 2004 10:53:01 -0600 (CST) Date: Wed, 31 Mar 2004 10:53:01 -0600 From: "Jacques A. Vidrine" To: Oliver Eikemeier Message-ID: <20040331165301.GA13952@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Oliver Eikemeier , Michael Nottebrock , FreeBSD Security References: <40687E18.9060907@fillmore-labs.com> <20040329201926.GA88529@madman.celabo.org> <40689343.4080602@fillmore-labs.com> <4068A0AF.2090807@gmx.net> <4068A90A.7000104@fillmore-labs.com> <4068B881.4010304@gmx.net> <20040330045646.GD5998@madman.celabo.org> <406912E7.4040806@gmx.net> <20040330142416.GJ10949@lum.celabo.org> <40699B09.5020107@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40699B09.5020107@fillmore-labs.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: FreeBSD Security Subject: Re: cvs commit: ports/multimedia/xine Makefile X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 16:53:02 -0000 On Tue, Mar 30, 2004 at 06:06:33PM +0200, Oliver Eikemeier wrote: > Jacques A. Vidrine wrote: > > >[...] > >In that fashion, users have a choice of security policy. > > Could you elaborate a bit what you mean with `choice of > security policy'? Which different security policies are > there to choose from? Sure. Here are several invented security policies: (a) Do not install ports that have been marked FORBIDDEN. (This is the current de facto security policy.) (b) Do not install ports that have been entered into the VuXML document, and warn me of any of those that are already installed. (portaudit implements this policy) (c) Except for issues that I've marked ignore, do not install/warn me about ports that have been entered into the VuXML document. (My favorite policy.) (d) Shutdown if any ports are installed that are listed in the VuXML document. (I'm just being silly.) (e) Do not install ports with MAINTAINER=idiot@FreeBSD.org, and warn me of any of those that are already installed. (I'm just being silly.) (f) Someone could potentially maintain an adjunct database that lists just ``serious'' (by that person's definition of ``serious'') issues by VuXML ID. Do not install ports in that adjunct database. Hmm. Scenario (f) is essentially what you get when one adds FORBIDDEN= http://vuxml.freebsd.org/...vid...html to a port Makefile. As we've agreed before, ``FORBIDDEN'' is an explicity severity indicator. Other than selecting a default policy, we don't have to choose only a single one of these, but only provide tools for implementing such policies. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Sat Apr 3 07:34:38 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAB1416A4CE for ; Sat, 3 Apr 2004 07:34:38 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4572143D48 for ; Sat, 3 Apr 2004 07:34:38 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))verified)) by gw.celabo.org (Postfix) with ESMTP id D54225482B for ; Sat, 3 Apr 2004 09:34:37 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 875B76D465; Sat, 3 Apr 2004 09:34:37 -0600 (CST) Date: Sat, 3 Apr 2004 09:34:37 -0600 From: "Jacques A. Vidrine" To: freebsd-security@FreeBSD.org Message-ID: <20040403153437.GA80671@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-security@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i Subject: Security branch lifetime changes X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2004 15:34:38 -0000 Hi Folks, I have extended the lifetime of the RELENG_4_8 security branch, and of security branches in general: ----- Forwarded message from Jacques Vidrine ----- Date: Sat, 3 Apr 2004 07:23:54 -0800 (PST) From: Jacques Vidrine To: doc-committers@FreeBSD.org, cvs-doc@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: www/en/security security.sgml Message-Id: <200404031523.i33FNsqq079309@repoman.freebsd.org> nectar 2004/04/03 07:23:54 PST FreeBSD doc repository Modified files: en/security security.sgml Log: Add text explaining new guidelines for the lifetimes of security branches. `Early adopter' branches will be supported 6+ months, `Normal' branches will be supported 12+ months, and `Extended' branches will be supported 24+ months. Mark RELENG_4_8 as an `Extended' support branch and extend its Estimated EoL accordingly. While here, also extend RELENG_5_2 through the end of 2004. (I was reminded that RELENG_4_8 had expired a few days ago by cperciva@.) Revision Changes Path 1.152 +38 -16 www/en/security/security.sgml ----- End forwarded message ----- You may also find an excerpt from the updated http://www.freebsd.org/security/ page below the signature of this message. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or `Extended'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from the -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. The current designation and estimated lifetimes of the currently supported branches are given below. The Estimated EoL (end-of-life) column gives the earliest date on which that branch is likely to be dropped. Please note that these dates may be extended into the future, but only extenuating circumstances would lead to a branch's support being dropped earlier than the date listed. +--------------------------------------------------------+ | Branch | Release | Type | Estimated EoL | |----------+-------------+-------------+-----------------| |RELENG_4 |n/a |n/a |March 31, 2005 | |----------+-------------+-------------+-----------------| |RELENG_4_8|4.8-RELEASE |Extended |March 31, 2005 | |----------+-------------+-------------+-----------------| |RELENG_5_2|5.2.1-RELEASE|Early adopter|December 31, 2004| |----------+-------------+-------------+-----------------| |RELENG_4_9|4.9-RELEASE |Normal |October 31, 2004 | +--------------------------------------------------------+ Older releases are not maintained and users are strongly encouraged to upgrade to one of the supported releases mentioned above. From owner-freebsd-security@FreeBSD.ORG Sat Apr 3 07:55:59 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E13C16A4CE for ; Sat, 3 Apr 2004 07:55:59 -0800 (PST) Received: from mail.ctch.net (mail.ctch.net [206.168.231.99]) by mx1.FreeBSD.org (Postfix) with SMTP id 4885843D5D for ; Sat, 3 Apr 2004 07:55:59 -0800 (PST) (envelope-from gkuhn@ctch.net) Received: (qmail 16083 invoked from network); 3 Apr 2004 15:55:58 -0000 Received: from 63-227-123-177.dnvr.qwest.net (HELO user-1l60wscfjd.ctch.net) (gkuhn@ctch.net@63.227.123.177) by mail.ctch.net with SMTP; 3 Apr 2004 15:55:58 -0000 Message-Id: <6.0.0.22.2.20040403085127.02731948@mail.ctch.net> X-Sender: gkuhn@ctch.net@mail.ctch.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 03 Apr 2004 08:55:56 -0700 To: freebsd-security@FreeBSD.org From: Gregory Kuhn In-Reply-To: <20040403153437.GA80671@madman.celabo.org> References: <20040403153437.GA80671@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: Security branch lifetime changes X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2004 15:55:59 -0000 At 08:34 AM 4/3/2004, you wrote: >Hi Folks, > >I have extended the lifetime of the RELENG_4_8 security branch, and of >security branches in general: >+--------------------------------------------------------+ >| Branch | Release | Type | Estimated EoL | >|----------+-------------+-------------+-----------------| >|RELENG_4 |n/a |n/a |March 31, 2005 | >|----------+-------------+-------------+-----------------| >|RELENG_4_8|4.8-RELEASE |Extended |March 31, 2005 | >|----------+-------------+-------------+-----------------| Dear Jacques, Thank you, thank you, thank you. 8-) My company has been quite pleased with the performance of FBSD 4.8 and I was not looking forward to having to upgrade just yet. It is good to know that I have one more year to prepare for the upgrade. Gregory Kuhn From owner-freebsd-security@FreeBSD.ORG Sat Apr 3 11:01:59 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CF2E16A4CE for ; Sat, 3 Apr 2004 11:01:59 -0800 (PST) Received: from you.fuckup.org (you.fuckup.org [216.150.215.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id C097743D45 for ; Sat, 3 Apr 2004 11:01:58 -0800 (PST) (envelope-from stephen@sonn.com) Received: from you.fuckup.org (stanley@localhost [127.0.0.1]) by you.fuckup.org (8.12.9p2/8.12.9) with ESMTP id i33J1vTO046348; Sat, 3 Apr 2004 12:01:57 -0700 (MST) (envelope-from stephen@sonn.com) Received: (from stain@localhost) by you.fuckup.org (8.12.9p2/8.12.8/Submit) id i33J1uLs046347; Sat, 3 Apr 2004 12:01:56 -0700 (MST) (envelope-from stephen@sonn.com) X-Authentication-Warning: you.fuckup.org: stain set sender to stephen@sonn.com using -f Date: Sat, 3 Apr 2004 12:01:56 -0700 From: Stephen Rozzo To: freebsd-security@freebsd.org Message-ID: <20040403190156.GA45280@sonn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.4.1i X-PGP-PubKey: http://www.kaosol.net/~stain/pubkey.asc X-PGP-Fingerprint: BCED 4293 BD7B 4C05 AB1E 3F61 15ED 3FFC 9C8A 39C6 X-Virus-Scanned: by amavisd-new Subject: IPSec Racoon and Port Forwarding X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2004 19:01:59 -0000 Hello, I have given myself quite the headache trying to make this VPN work correc= tly. I am attempting to use racoon to establish keys and construct an encry= pted tunnel between one host(A.A.A.A) with a routable IP address and anothe= r that has a private address(10.0.0.2) with a cable modem(B.B.B.B) forwardi= ng all ports to the private address(10.0.0.2). Here is a quick topographic = dipiction of the infastructure:=20 =20 192.168.121.0/24=09 ------------------ | | _____|_____=20 | |priv_int 192.168.121.253 VPN Gateway(1) | | |___________|pub_int A.A.A.A | ~~~~~~~~~~~~~ Internet ~~~~~~~~~~~~~ _____|_____ | | Cable Modem | |pub_int B.B.B.B(forwarded to 10.0.0.2)= =20 |___________| _____|_____ =20 | |pub/priv_int 10.0.0.2 VPN Gateway(2) | | |___________|priv_int 192.168.122.254=20 | | | ------------------ 192.168.122.0/24 Here is what I have in ipsec.conf on VPN Gateway (1): flush; spdflsuh; spdadd A.A.A.A/32 B.B.B.B/32 ipencap -P out ipsec esp/tunnel/A.A.A.A-B.B.B.= B/require; spdadd B.B.B.B/32 A.A.A.A/32 ipencap -P in ipsec esp/tunnel/B.B.B.B-A.A.A.A= /require; ifconfig output: dc0: flags=3D8843 mtu 1500 inet 192.168.121.253 netmask 0xffffff00 broadcast 192.168.121.255 ether 00:a0:cc:d1:a2:df media: Ethernet autoselect (100baseTX ) status: active dc1: flags=3D8843 mtu 1500 inet A.A.A.A netmask 0xfffffff8 broadcast 216.160.154.159 ether 00:a0:cc:62:f0:6a media: Ethernet autoselect (100baseTX ) status: active gif1: flags=3D8051 mtu 1280 tunnel inet A.A.A.A --> B.B.B.B=20 inet 192.168.121.253 --> 192.168.122.254 netmask 0xffffffff VPN Gateway 2(10.0.0.1) ipsec.conf: spdadd 0.0.0.0/0 A.A.A.A/32 ipencap -P out ipsec esp/tunnel/10.0.0.2-A.A.A.= A/require; spdadd A.A.A.A/32 0.0.0.0/0 ipencap -P in ipsec esp/tunnel/A.A.A.A-10.0.0.2= /require; ifconfig output: bge0: flags=3D8843 mtu 1500 options=3D3 inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:0e:7f:ff:0e:0c media: Ethernet autoselect (10baseT/UTP ) status: active xl0: flags=3D8843 mtu 1500 options=3D3 inet 192.168.122.254 netmask 0xffffff00 broadcast 192.168.122.255 ether 00:04:75:8b:80:ce media: Ethernet autoselect (100baseTX ) status: active gif0: flags=3D8051 mtu 1280 tunnel inet 10.0.0.2 --> A.A.A.A=20 inet 192.168.122.254 --> 192.168.121.253 netmask 0xffffffff Until I instate a SP for these two hosts I can pass traffic back and forth = to both private subnets (192.168.X.X) just fine. Once I read in these ipsec= policies I can not get any traffic back and forth.. Any suggestions? I loo= ked numerous places and found no one else documenting problems or success. Thanks