From owner-freebsd-security@FreeBSD.ORG Sun Jul 27 03:48:04 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACCD3106567D for ; Sun, 27 Jul 2008 03:48:04 +0000 (UTC) (envelope-from chris@noncombatant.org) Received: from strawberry.noncombatant.org (strawberry.noncombatant.org [64.142.6.126]) by mx1.freebsd.org (Postfix) with ESMTP id 8663C8FC0A for ; Sun, 27 Jul 2008 03:48:04 +0000 (UTC) (envelope-from chris@noncombatant.org) Received: from [10.0.0.102] (unknown [64.142.6.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by strawberry.noncombatant.org (Postfix) with ESMTPSA id 3B67B866B94; Sat, 26 Jul 2008 20:48:04 -0700 (PDT) Message-Id: <2E998E52-257B-47BF-917F-4FB41E9D5854@noncombatant.org> From: Chris Palmer To: Matthew Dillon , Liste FreeBSD-security In-Reply-To: <200807242320.m6ONKPgW007279@apollo.backplane.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 26 Jul 2008 20:48:03 -0700 References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> X-Mailer: Apple Mail (2.926) Cc: Subject: Re: A new kind of security needed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2008 03:48:04 -0000 On Jul 24, 2008, at 4:20 PM, Matthew Dillon wrote: > I think the best way to approach the problem is to work out the > desired > userland API first... find the easiest and most convenient way to > wrap > an application, what kind of features are desired, etc, and then > implement it. I think Szilveszter Adam was right to point out that any such system needs to work with the user, and support what the user needs in a way that fits well with they interact with an application. Rather than being the easiest and most convenient (for the developer), the API should be the simplest means to provide what the user needs. That may have been what you meant when you said "what kinds of features are desired", though. There's a great book that covers a wide range of security and usability topics called *Security and Usability: Designing Secure Systems That People Can Use*, by Cranor and Garfinkel. I highly recommend it. http://books.google.com/books?id=wDVhy9EyEAEC&dq=lorrie+faith+cranor+simson+garfinkel+usable+security&pg=PP1&ots=BOKHuIHr2u&sig=e-DoE4ap0ldkxffFqUs8LaROmYc&hl=en&sa=X&oi=book_result&resnum=1&ct=result From owner-freebsd-security@FreeBSD.ORG Mon Jul 28 19:28:40 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19C20106568D for ; Mon, 28 Jul 2008 19:28:40 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id AF0528FC19 for ; Mon, 28 Jul 2008 19:28:39 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so288681qwb.7 for ; Mon, 28 Jul 2008 12:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SqhU6WIcury6c0cQBbGEC8kTaajl4mMEs0kDczy2Vos=; b=aI4c1yCNGF8t+5kw3v9o6QZ3Q0sg32xKz/X/JiFVdb4CD4uGhx5FwqabBnTTeufHqe /z4x0cfhFTjFwP7fng0tD5HxUL1ZnPfDmavX9lsNWGEOmwsTICYvmx7nmtAkxyMIssoN e0U27Vx6WYRFoGYIgIlYbml4fTv0/7tlO+pjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=W5SKiLggQFyHbAGPgOgFRENxNm7FMU4h7zCo0sWKDoKbRYb7BkG4Qwb1CREturKYPW i/tLR8eKUP7ykERZoVb9CCddRUMVU8WhOhMtmqHvrxqEYkMuLma2FEKzXMC5Izo8Otu1 53uQIW6ysNaQYB96h8cXNdQ77AbR7sAETXnbQ= Received: by 10.214.241.21 with SMTP id o21mr282446qah.60.1217273318916; Mon, 28 Jul 2008 12:28:38 -0700 (PDT) Received: by 10.150.200.14 with HTTP; Mon, 28 Jul 2008 12:28:38 -0700 (PDT) Message-ID: Date: Mon, 28 Jul 2008 12:28:38 -0700 From: "Matt Reimer" To: "Szilveszter Adam" In-Reply-To: <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> Cc: freebsd-security@freebsd.org Subject: Re: A new kind of security needed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 19:28:40 -0000 On Thu, Jul 24, 2008 at 9:56 PM, Szilveszter Adam wrote: > On Fri, Jul 25, 2008 at 01:18:25PM +1000, Tim Clewlow wrote: >> Some more thoughts. > > <...> > >> The existing DAC method already provides sufficient protection (we >> all hope) to system objects, often via root/wheel. What we really >> want is a mechanism to protect user data from being clobbered by an >> errant program. By extending the traditional DAC with an Application >> ID (AID) the kernel could allow or deny processes that are part of a >> particular application from accessing a file based on the rwx flags >> of the AID for a particular user file. > > This idea may work quite well for a server (and already does, there are > several implementations out there). But for an interactive desktop > software that a user drives in real-time (like firefox, as you mention) > this does not work. Think about it: You want firefox to not touch your > files in your ~ directory, so you configure FF in this way. But then, > somehow you come to the very unlikely idea that you want to actually > download something from the web. (eg a PDF manual for the latest gadget > that you bought) Or upload one of your photos to an > online album (as Robert Watson has already pointed out). What now? FF is > not allowed to touch your files, so will not be able to do at least the > first case (because that requires write access to some location in order > to save the file) but quite possibly the second may not work either, > after all, why would you want FF to read your office documents, so you > have already denied that as well. > > There is no secure and usable solution to this problem, as Robert has > already pointed out. The whole notion of sandboxing rests on the idea > that the behaviour of an application is very deterministic (it only does > A, and never, ever, anything else, during normal operation) and not very > complex. Typical desktop software is already very complex, has a lot of > functions and is not deterministic almost by design: there is a human > sitting in front of it, doing this on one occassion and something else > on another. If you allow everything that the functions of the software > might cover (or only a reasonable set) you are already almost at the > status-quo: You have to allow access to many-many objects, many of which > are not in use most of the time, some are not in use ever, but who > knows. My idea was to basically have a secure file picker that grants the app (e.g. Firefox) access to the file, in a way that would be transparent to the user. For example, when Firefox wants to save a PDF it displays the file picker as usual and the file is saved. Underneath what's happening is that Firefox talks to the trusted system filepicker via a socket, and depending on the user's input it grants access to the file, whether temporarily or permanently. If Firefox is using the standard GTK file picker, then only GTK would need to be changed. Matt From owner-freebsd-security@FreeBSD.ORG Tue Jul 29 00:25:24 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E9011065676 for ; Tue, 29 Jul 2008 00:25:24 +0000 (UTC) (envelope-from jeff+freebsd@wagsky.com) Received: from mail.wagsky.com (wildside.wagsky.com [64.220.148.97]) by mx1.freebsd.org (Postfix) with ESMTP id 308D68FC13 for ; Tue, 29 Jul 2008 00:25:24 +0000 (UTC) (envelope-from jeff+freebsd@wagsky.com) Received: from port5.pn.wagsky.com (port5.pn.wagsky.com [192.168.6.5]) by mail.wagsky.com (Postfix) with ESMTPSA id 6D19D28445; Mon, 28 Jul 2008 17:07:53 -0700 (PDT) Message-ID: <488E5F5A.3050209@wagsky.com> Date: Mon, 28 Jul 2008 17:07:54 -0700 From: Jeff Kletsky User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw "bug" - recv any = not recv any X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2008 00:25:24 -0000 I hesitate to call this a "bug" as I don't know all the history behind the ipfw2 decisions, so let me toss this out there and see I'm just missing something. Overview ======== The negated operator, "not recv any" was taken to mean "any packet never received by an interface" believed to be equivalent to "any packet that originated on the current machine's interfaces" My logic being: * If "recv any" means "received by any interface" * then "not recv any" means "not received by any interface" (which should be locally-generated packets) In practice, both "recv any" and "not recv any" appear to be "no-op" phrases. Application was to be able to discriminate between: * Packets from the current host that are going out (and need stateful rules of the form my.outside.IP <==> some.rest.of.world.host) * Packets received from "inside" hosts that had been NAT-ed (and need to be let out without another stateful rule, as one was created when the packet was received of the form my.private.net.IP <==> some.rest.of.world.host) Agreed, there are ways to solve this in ipfw2 (tagging, for one), but the issue is that there is at least one "reasonable" application for the phrase and that the behavior is not what one might expect, in a potentially dangerous way. To replicate ============ 1) Identify a "blank" rule [root@wildside /etc/firewall]# ipfw list 20000 ipfw: rule 20000 does not exist 2) create a rule that does not modify traffic, but logs matches, using "not recv any" [root@wildside /etc/firewall]# ipfw add 20000 count all from any to any out not recv any 20000 count ip from any to any out 2a) Expect that (2) would have indication that "not recv any" was present 3) delete the rule just created and create another that is identical, but without the "not" modifier [root@wildside /etc/firewall]# ipfw delete 20000 [root@wildside /etc/firewall]# ipfw add 20000 count all from any to any out recv any 20000 count ip from any to any out 3a) Note that the generated rule is the same (enabling logging confirms that both "recv any" and "not recv any" appear to be NOOPs) Discussion ========== I didn't find much here, but did dig up an older post that looked to be discussing this kind of thing > From: Patrick O'Reilly > Date: 11 Mar 2001 23:47:44 In my opinion, the following would be "ideal" 1) "recv any" -- matches packets that have been received by the host through one of its interfaces 2) "not recv any" -- does not match packets that have been received by the host through one of its interfaces Unfortunately, implementing (1) would likely break a lot of people's rule sets (2), however, I can't immediately see being used without expecting that it would fail to match packets that were received by the current host, so its implementation would be a bit "safer" for the community I took a quick look at the code, as Patrick's message suggests matching "NULL" > Likewise, Rod Grimes suggested: > ------------------ > No, but it should be trivial to patch the code to allow your !any, if > you consider that !any is the same as =null: > > ipfw count ip from any to any in recv null > > Ie, the recv keyword looks at the ifp in the mbuff, the ifp will be null > for packets originated on the local machine. /usr/src/sys/netinet/ip_fw2.c -- seemed to be the place, but the start of the s/r that caught my eye is not immediately suggesting that there is a way to match a null ifp without patching code as its trapped before the check is done static int iface_match(struct ifnet *ifp, ipfw_insn_if *cmd) { if (ifp == NULL) /* no iface with this packet, match fails */ return 0; /* Check by name or by IP address */ if (cmd->name[0] != '\0') { /* match by name */ /* Check name */ if (cmd->p.glob) { if (fnmatch(cmd->name, ifp->if_xname, 0) == 0) return(1); } else { if (strncmp(ifp->if_xname, cmd->name, IFNAMSIZ) == 0) return(1); } Thoughts? Worth more than just a doc change? Thanks for the time, Jeff From owner-freebsd-security@FreeBSD.ORG Tue Jul 29 02:36:30 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C1C8106566B for ; Tue, 29 Jul 2008 02:36:30 +0000 (UTC) (envelope-from tim@clewlow.org) Received: from clewlow.org (clewlow.org [210.215.149.194]) by mx1.freebsd.org (Postfix) with ESMTP id 8D9428FC2C for ; Tue, 29 Jul 2008 02:36:29 +0000 (UTC) (envelope-from tim@clewlow.org) Received: from 192.168.1.100 (localhost [127.0.0.1]) by clewlow.org (Postfix) with ESMTP id 887EA1C081D for ; Tue, 29 Jul 2008 12:36:27 +1000 (EST) Received: from 192.168.1.10 (SquirrelMail authenticated user tim) by 192.168.1.100 with HTTP; Tue, 29 Jul 2008 12:36:27 +1000 (EST) Message-ID: <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> In-Reply-To: References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> Date: Tue, 29 Jul 2008 12:36:27 +1000 (EST) From: "Tim Clewlow" To: freebsd-security@freebsd.org User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: A new kind of security needed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2008 02:36:30 -0000 On Thu, Jul 24, 2008 at 9:56 PM, Szilveszter Adam wrote: > On Fri, Jul 25, 2008 at 01:18:25PM +1000, Tim Clewlow wrote: >> Some more thoughts. > > <...> > >> The existing DAC method already provides sufficient protection (we >> all hope) to system objects, often via root/wheel. What we really >> want is a mechanism to protect user data from being clobbered by an >> errant program. By extending the traditional DAC with an Application >> ID (AID) the kernel could allow or deny processes that are part of a >> particular application from accessing a file based on the rwx flags >> of the AID for a particular user file. > > This idea may work quite well for a server (and already does, there are > several implementations out there). But for an interactive desktop > software that a user drives in real-time (like firefox, as you mention) > this does not work. Think about it: You want firefox to not touch your > files in your ~ directory, so you configure FF in this way. But then, > somehow you come to the very unlikely idea that you want to actually > download something from the web. (eg a PDF manual for the latest gadget > that you bought) Or upload one of your photos to an > online album (as Robert Watson has already pointed out). What now? FF is > not allowed to touch your files, so will not be able to do at least the > first case (because that requires write access to some location in order > to save the file) but quite possibly the second may not work either, > after all, why would you want FF to read your office documents, so you > have already denied that as well. > > There is no secure and usable solution to this problem, as Robert has > already pointed out. The whole notion of sandboxing rests on the idea > that the behaviour of an application is very deterministic (it only does > A, and never, ever, anything else, during normal operation) and not very > complex. Typical desktop software is already very complex, has a lot of > functions and is not deterministic almost by design: there is a human > sitting in front of it, doing this on one occassion and something else > on another. If you allow everything that the functions of the software > might cover (or only a reasonable set) you are already almost at the > status-quo: You have to allow access to many-many objects, many of which > are not in use most of the time, some are not in use ever, but who > knows. I'd like to offer a possible solution that I believe can be both secure and usable. This will use the AID concept outlined above. (Note, when I refer to a rwx flag in the following paragraphs, I am talking about a flag in a 4th group, ie in addition to the normal user/group/other set of flags, lets call it the app set - in addition, there is an associated AID for any of the 3 of those flags that have been set, ie there can be up to 3 different application ID's set for a single user file) When a user file is created, the kernel sets the read flag, and sets the AID for that flag to 0 (0 being a special value), the intention being that this means any application can read the file. Next the kernel sets the the write flag, and set the AID for the write flag to be the same as the application that is creating the file. (If at some later time the user wants to limit reading to a single application, then they can with the equivalent of a chmod for AID) Using this method, an errant application will only be able to damage data files that it owns. It also means if an application wants to create a new file, then it can. This solves the problems presented above. (If the file about to be created already exists, then as long as the application owns the file, it should be allowed to overwrite it as it should already have write access) For systems with this enabled, ie desktop systems, this would, for the majority of data files, work quietly in the background without the user even being aware of what is going on. One place where some work would be required is during the installation or upgrade of an application, ie as part of the installation, there would need to be some provision for acquiring the AID that the application will eventually be given by the kernel, and then setting the write AID value accordingly for any data / config files that may be created during installation. This is part of what I was referring to when I said the implementation of AID would create a system that has some important differences from a vanilla FreeBSD system. Anyway, I just wanted to offer this as being a potential way of overcoming some of the pitfalls pointed out above. Yes I know I am being persistant, and probably a bit annoying too. I dont mean it to be, I just would like to explore the possibilities of enhanced security that may be available. Feel free to shoot holes in any/all of this, I may have painted a big target here :-) Cheers, Tim. From owner-freebsd-security@FreeBSD.ORG Tue Jul 29 05:12:59 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDD12106566B for ; Tue, 29 Jul 2008 05:12:59 +0000 (UTC) (envelope-from sziszi@bsd.hu) Received: from mail.rubicom.hu (mail.rubicom.hu [89.147.80.28]) by mx1.freebsd.org (Postfix) with ESMTP id 6EC6D8FC15 for ; Tue, 29 Jul 2008 05:12:59 +0000 (UTC) (envelope-from sziszi@bsd.hu) Received: from localhost ([127.0.0.1] helo=mail.rubicom.hu) by mail.rubicom.hu with smtp (Exim 4.63) (envelope-from ) id 1KNhW4-0006y6-Tm for freebsd-security@freebsd.org; Tue, 29 Jul 2008 07:12:56 +0200 Received: from ip5993549e.rubicom.hu ([89.147.84.158] helo=baranyfelhocske.buza.adamsfamily.xx) by mail.rubicom.hu with esmtp (Exim 4.63) (envelope-from ) id 1KNhVs-0006sk-4O for freebsd-security@freebsd.org; Tue, 29 Jul 2008 07:12:44 +0200 Received: from baranyfelhocske.buza.adamsfamily.xx (localhost [127.0.0.1]) by baranyfelhocske.buza.adamsfamily.xx (8.14.2/8.14.2) with ESMTP id m6T5Cf50002195 for ; Tue, 29 Jul 2008 07:12:41 +0200 (CEST) (envelope-from sziszi@bsd.hu) Received: (from sziszi@localhost) by baranyfelhocske.buza.adamsfamily.xx (8.14.2/8.14.2/Submit) id m6T5CfNa002194 for freebsd-security@freebsd.org; Tue, 29 Jul 2008 07:12:41 +0200 (CEST) (envelope-from sziszi@bsd.hu) X-Authentication-Warning: baranyfelhocske.buza.adamsfamily.xx: sziszi set sender to sziszi@bsd.hu using -f Date: Tue, 29 Jul 2008 07:12:41 +0200 From: Szilveszter Adam To: freebsd-security@freebsd.org Message-ID: <20080729051241.GA1995@baranyfelhocske.buza.adamsfamily.xx> References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: A new kind of security needed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2008 05:13:00 -0000 On Mon, Jul 28, 2008 at 12:28:38PM -0700, Matt Reimer wrote: > My idea was to basically have a secure file picker that grants the app > (e.g. Firefox) access to the file, in a way that would be transparent > to the user. For example, when Firefox wants to save a PDF it displays > the file picker as usual and the file is saved. Underneath what's > happening is that Firefox talks to the trusted system filepicker via a > socket, and depending on the user's input it grants access to the > file, whether temporarily or permanently. > > If Firefox is using the standard GTK file picker, then only GTK would > need to be changed. Well, you have snipped the part of my message that deals with this: The mere idea of "trusted" system components is faulty. There is nothing on a standard PC that you can trust, when it comes down to it. Not even the hardware. Remember, if you can install a new application, a malware author can do the same. It only takes one hole in such a "trusted" service, and all of your machine is 0wned. There is a very long history of such disasters on Windows, where it is quite common to split software in two parts: one that runs with priviledge in the background as a service (you could say a daemon on Unix) and one that runs as the user and displays the GUI. Many anti-virus products work this way. There have been just too many cases when this design just blew up and led to a system compromise instead of just eg deleting all the jpg-s of the user. Security is a complex matter... -- Regards: Szilveszter ADAM Budapest Hungary From owner-freebsd-security@FreeBSD.ORG Tue Jul 29 04:59:25 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C505A106567E for ; Tue, 29 Jul 2008 04:59:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outT.internet-mail-service.net (outt.internet-mail-service.net [216.240.47.243]) by mx1.freebsd.org (Postfix) with ESMTP id BA2908FC14 for ; Tue, 29 Jul 2008 04:59:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 7720724C9; Mon, 28 Jul 2008 21:59:25 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id B8E2A2D603A; Mon, 28 Jul 2008 21:59:24 -0700 (PDT) Message-ID: <488EA31B.9070707@elischer.org> Date: Mon, 28 Jul 2008 21:56:59 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Jeff Kletsky References: <488E5F5A.3050209@wagsky.com> In-Reply-To: <488E5F5A.3050209@wagsky.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 29 Jul 2008 11:47:59 +0000 Cc: freebsd-security@freebsd.org Subject: Re: ipfw "bug" - recv any = not recv any X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2008 04:59:25 -0000 Jeff Kletsky wrote: > I hesitate to call this a "bug" as I don't know all the history behind > the ipfw2 decisions, so let me toss this out there and see I'm just > missing something. > > Overview > ======== > > The negated operator, "not recv any" was taken to mean "any packet never > received by an interface" believed to be equivalent to "any packet that > originated on the current machine's interfaces" > > My logic being: > * If "recv any" means "received by any interface" > * then "not recv any" means "not received by any interface" (which > should be locally-generated packets) > > In practice, both "recv any" and "not recv any" appear to be "no-op" > phrases. > > > > Application was to be able to discriminate between: > > * Packets from the current host that are going out > (and need stateful rules of the form > my.outside.IP <==> some.rest.of.world.host) > > * Packets received from "inside" hosts that had been NAT-ed > (and need to be let out without another stateful rule, as one was > created when the packet was received of the form > my.private.net.IP <==> some.rest.of.world.host) > > Agreed, there are ways to solve this in ipfw2 (tagging, for one), but > the issue is that there is at least one "reasonable" application for the > phrase and that the behavior is not what one might expect, in a > potentially dangerous way. > > To replicate > ============ > > 1) Identify a "blank" rule > > [root@wildside /etc/firewall]# ipfw list 20000 > ipfw: rule 20000 does not exist > > 2) create a rule that does not modify traffic, but logs matches, using > "not recv any" > > [root@wildside /etc/firewall]# ipfw add 20000 count all from any to any > out not recv any > 20000 count ip from any to any out > > 2a) Expect that (2) would have indication that "not recv any" was present > > 3) delete the rule just created and create another that is identical, > but without the "not" modifier > > [root@wildside /etc/firewall]# ipfw delete 20000 > [root@wildside /etc/firewall]# ipfw add 20000 count all from any to any > out recv any > 20000 count ip from any to any out > > 3a) Note that the generated rule is the same > > (enabling logging confirms that both "recv any" and "not recv any" > appear to be NOOPs) > > > Discussion > ========== > > I didn't find much here, but did dig up an older post that looked to be > discussing this kind of thing > > > > > From: Patrick O'Reilly > > Date: 11 Mar 2001 23:47:44 > > > In my opinion, the following would be "ideal" > > 1) "recv any" -- matches packets that have been received by the host > through one of its interfaces > 2) "not recv any" -- does not match packets that have been received by > the host through one of its interfaces > > Unfortunately, implementing (1) would likely break a lot of people's > rule sets > > (2), however, I can't immediately see being used without expecting that > it would fail to match packets that were received by the current host, > so its implementation would be a bit "safer" for the community > how does "not recv *" (appropriatly escaped for your shell) do? > > > I took a quick look at the code, as Patrick's message suggests matching > "NULL" > > > Likewise, Rod Grimes suggested: > > ------------------ > > No, but it should be trivial to patch the code to allow your !any, if > > you consider that !any is the same as =null: > > > ipfw count ip from any to any in recv null > > > Ie, the recv keyword looks at the ifp in the mbuff, the ifp will be > null > > for packets originated on the local machine. > > /usr/src/sys/netinet/ip_fw2.c -- seemed to be the place, but the start > of the s/r that caught my eye is not immediately suggesting that there > is a way to match a null ifp without patching code as its trapped before > the check is done > > static int > iface_match(struct ifnet *ifp, ipfw_insn_if *cmd) > { > if (ifp == NULL) /* no iface with this packet, match fails */ > return 0; > /* Check by name or by IP address */ > if (cmd->name[0] != '\0') { /* match by name */ > /* Check name */ > if (cmd->p.glob) { > if (fnmatch(cmd->name, ifp->if_xname, 0) == 0) > return(1); > } else { > if (strncmp(ifp->if_xname, cmd->name, IFNAMSIZ) == 0) > return(1); > } > > > > Thoughts? > > Worth more than just a doc change? > > Thanks for the time, > > Jeff > > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Tue Jul 29 14:38:16 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C596E1065679 for ; Tue, 29 Jul 2008 14:38:16 +0000 (UTC) (envelope-from jeff+freebsd@wagsky.com) Received: from mail.wagsky.com (wildside.wagsky.com [64.220.148.97]) by mx1.freebsd.org (Postfix) with ESMTP id A74E88FC15 for ; Tue, 29 Jul 2008 14:38:16 +0000 (UTC) (envelope-from jeff+freebsd@wagsky.com) Received: from port5.pn.wagsky.com (port5.pn.wagsky.com [192.168.6.5]) by mail.wagsky.com (Postfix) with ESMTPSA id DF6982844A; Tue, 29 Jul 2008 07:38:15 -0700 (PDT) Message-ID: <488F2B57.7000706@wagsky.com> Date: Tue, 29 Jul 2008 07:38:15 -0700 From: Jeff Kletsky User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ipfw "bug" - recv any = not recv any X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2008 14:38:16 -0000 > In practice, both "recv any" and "not recv any" appear to be "no-op" > phrases. > [...] > In my opinion, the following would be "ideal" > > 1) "recv any" -- matches packets that have been received by the host > through one of its interfaces > 2) "not recv any" -- does not match packets that have been received by > the host through one of its interfaces > > Unfortunately, implementing (1) would likely break a lot of people's > rule sets > > (2), however, I can't immediately see being used without expecting that > it would fail to match packets that were received by the current host, > so its implementation would be a bit "safer" for the community > Julian Elishcher suggested: > how does "not recv *" (appropriatly escaped for your shell) do? This does appear to "work as desired" -- suggesting documentation clarification rather than functionality change My apologies for not posting to the ipfw list. Jeff From owner-freebsd-security@FreeBSD.ORG Wed Jul 30 11:41:51 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD5DF106567B for ; Wed, 30 Jul 2008 11:41:51 +0000 (UTC) (envelope-from mail@maxlor.com) Received: from popeye1.ggamaur.net (popeye1.ggamaur.net [213.160.40.50]) by mx1.freebsd.org (Postfix) with ESMTP id 62F508FC19 for ; Wed, 30 Jul 2008 11:41:51 +0000 (UTC) (envelope-from mail@maxlor.com) Received: from maxlor.mine.nu (c-82-192-240-247.customer.ggaweb.ch [82.192.240.247]) by popeye1.ggamaur.net (8.13.7/8.13.7/Submit) with ESMTP id m6UB11GK095576; Wed, 30 Jul 2008 13:01:03 +0200 (CEST) (envelope-from mail@maxlor.com) Received: from localhost (unknown [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id 0D76B2E3BA; Wed, 30 Jul 2008 13:00:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at atlantis.intranet Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (atlantis.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz4dExvsIaGu; Wed, 30 Jul 2008 13:00:55 +0200 (CEST) Received: from [192.168.10.161] (pub212004072186.fx-hfc.datazug.ch [212.4.72.186]) by maxlor.mine.nu (Postfix) with ESMTPSA id BD5052E3B7; Wed, 30 Jul 2008 13:00:55 +0200 (CEST) From: Benjamin Lutz To: freebsd-security@freebsd.org Date: Wed, 30 Jul 2008 13:00:54 +0200 User-Agent: KMail/1.9.9 References: <60254.1216921273@critter.freebsd.dk> <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> In-Reply-To: <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> X-Face: $Ov27?7*N,h60fIEfNJdb!m,@#4T/d; 1hw|W0zvsHM(a$Yn6BYQ0^SEEXvi8>D`|V*F"=?iso-8859-1?q?=5F+=0A=09R2?=@Aq>+mNb4`,'[[%z9v0Fa~]AD1}xQO3|>b.z&}l#R-_(P`?@Mz"kS; XC>Eti,i3>%@=?iso-8859-1?q?g=3F=0A=094f?=,\c7|Ghwb&ky$b2PJ^\0b83NkLsFKv|smL/cI4UD%Tu8alAD MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807301300.54490.mail@maxlor.com> X-Scanned-By: MIMEDefang 2.64 on 213.160.40.60 Cc: Tim Clewlow Subject: Re: A new kind of security needed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 11:41:51 -0000 On Tuesday 29 July 2008 04:36:27 Tim Clewlow wrote: > I'd like to offer a possible solution that I believe can be both > secure and usable. This will use the AID concept outlined above. > > (Note, when I refer to a rwx flag in the following paragraphs, I am > talking about a flag in a 4th group, ie in addition to the normal > user/group/other set of flags, lets call it the app set - in > addition, there is an associated AID for any of the 3 of those flags > that have been set, ie there can be up to 3 different application > ID's set for a single user file) > > When a user file is created, the kernel sets the read flag, and sets > the AID for that flag to 0 (0 being a special value), the intention > being that this means any application can read the file. Next the > kernel sets the the write flag, and set the AID for the write flag > to be the same as the application that is creating the file. (If at > some later time the user wants to limit reading to a single > application, then they can with the equivalent of a chmod for AID) > > Using this method, an errant application will only be able to damage > data files that it owns. It also means if an application wants to > create a new file, then it can. This solves the problems presented > above. (If the file about to be created already exists, then as long > as the application owns the file, it should be allowed to overwrite > it as it should already have write access) Can you elaborate a bit more on what the AID for the x permission is going to look like? Obviously, there have to be applications with very wide-ranging permissions (a filemanager, tools like cp and mv, or the tool used to set AID permissions). Being able to execute them often means being able to change the target file freely and non-interactively (with cp for example). So most applications should not be able to execute cp, right?. However, what about programs whose main job it is to launch other processes, such as /bin/sh. How are you going to prevent some evil application from running /bin/sh -c "cp /dev/zero /very/important/file"? If you're now thinking, limit who can run /bin/sh, consider that some application launching programs can be controlled in other ways; KDE apps can often be controlled with DCOP for example. Cheers Benjamin From owner-freebsd-security@FreeBSD.ORG Sat Aug 2 19:17:21 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E91BE106568E for ; Sat, 2 Aug 2008 19:17:21 +0000 (UTC) (envelope-from chris@noncombatant.org) Received: from strawberry.noncombatant.org (strawberry.noncombatant.org [64.142.6.126]) by mx1.freebsd.org (Postfix) with ESMTP id C351C8FC19 for ; Sat, 2 Aug 2008 19:17:21 +0000 (UTC) (envelope-from chris@noncombatant.org) Received: from [10.0.0.102] (unknown [64.142.6.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by strawberry.noncombatant.org (Postfix) with ESMTPSA id 39ED6867092; Sat, 2 Aug 2008 12:17:21 -0700 (PDT) Message-Id: <5D233428-9099-4924-B7F0-3017FD3C3E77@noncombatant.org> From: Chris Palmer To: Matt Reimer , Liste FreeBSD-security In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 2 Aug 2008 12:17:20 -0700 References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> X-Mailer: Apple Mail (2.926) Cc: Subject: Re: A new kind of security needed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2008 19:17:22 -0000 On Jul 28, 2008, at 12:28 PM, Matt Reimer wrote: > My idea was to basically have a secure file picker that grants the app > (e.g. Firefox) access to the file, in a way that would be transparent > to the user. For example, when Firefox wants to save a PDF it displays > the file picker as usual and the file is saved. Underneath what's > happening is that Firefox talks to the trusted system filepicker via a > socket, and depending on the user's input it grants access to the > file, whether temporarily or permanently. How can the trusted system filepicker know that it is receiving messages from the true Firefox filepicker, and in response to true user gestures? (Basically, it can't.) Microsoft had to deal with this problem; see e.g. http://en.wikipedia.org/wiki/User_Account_Control. From owner-freebsd-security@FreeBSD.ORG Sat Aug 2 19:21:08 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDDD71065672 for ; Sat, 2 Aug 2008 19:21:08 +0000 (UTC) (envelope-from chris@noncombatant.org) Received: from strawberry.noncombatant.org (strawberry.noncombatant.org [64.142.6.126]) by mx1.freebsd.org (Postfix) with ESMTP id 8DEB68FC14 for ; Sat, 2 Aug 2008 19:21:08 +0000 (UTC) (envelope-from chris@noncombatant.org) Received: from [10.0.0.102] (unknown [64.142.6.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by strawberry.noncombatant.org (Postfix) with ESMTPSA id 4BEF0867092; Sat, 2 Aug 2008 12:21:08 -0700 (PDT) Message-Id: From: Chris Palmer To: Tim Clewlow , Liste FreeBSD-security In-Reply-To: <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) X-Priority: 3 (Normal) Date: Sat, 2 Aug 2008 12:21:07 -0700 References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> X-Mailer: Apple Mail (2.926) Cc: Subject: Re: A new kind of security needed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2008 19:21:08 -0000 On Jul 28, 2008, at 7:36 PM, Tim Clewlow wrote: > I'd like to offer a possible solution that I believe can be both > secure and usable. This will use the AID concept outlined above. What is an AID, and where does it come from? Is it a sequential uid_t assigned at install-time, is it the SHA-256 hash of the ELF file, or something else? What about programs that call dlopen(3) or which are controllable via RPC/LPC (Benjamin Lutz mentioned DCOP)? From owner-freebsd-security@FreeBSD.ORG Sat Aug 2 19:50:59 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E30D71065673 for ; Sat, 2 Aug 2008 19:50:59 +0000 (UTC) (envelope-from bob@sinister.com) Received: from neptune.sinister.com (neptune.sinister.com [65.18.170.128]) by mx1.freebsd.org (Postfix) with ESMTP id BC0F48FC18 for ; Sat, 2 Aug 2008 19:50:59 +0000 (UTC) (envelope-from bob@sinister.com) Received: from bob (helo=localhost) by neptune.sinister.com with local-esmtp (Exim 4.63) (envelope-from ) id 1KPMTx-00073y-Me for freebsd-security@freebsd.org; Sat, 02 Aug 2008 15:09:37 -0400 Date: Sat, 2 Aug 2008 15:09:37 -0400 (EDT) From: Bob Keyes To: freebsd-security@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 02 Aug 2008 22:29:12 +0000 Subject: The BIND scandal X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2008 19:51:00 -0000 What's really sad is that bad attitudes from various OS security organizations, such as some people at FreeBSD, has made some people less willing to share vulnerabilities that they have discovered. I speak specifically from my experience in the year 2000, regarding the NAPTHA DoS. Mr. Robert Watson was quite uncivilized in his criticisms of me and the disclosure, even though it had been handled in the most reasonable way (through CERT). You may not believe it, but I've known about this BIND problem for some years, but kept it in my vest pocket. Why? Because I was tired of being made to suffer for doing what was right. I have an inkling about other problems which affect commonly used open-source software, but I see no reason to do a thorough investigation and disclose the results in a responsible way. Because of the bad attitudes of a number of people in the security community, I've been very quiet, not revealing any of my accidental discoveries nor pursuing fixes for the problems I see. Until reasonable and diplomatic people are installed as the security contacts for organizations such as FreeBSD, I will only make patches available to me and my close friends. Perhaps I am wrong, and that people who flamed me for my disclosure have grown up. I'd like to think so. -R. Keyes From owner-freebsd-security@FreeBSD.ORG Sat Aug 2 23:03:27 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE769106564A for ; Sat, 2 Aug 2008 23:03:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3AA8FC0A for ; Sat, 2 Aug 2008 23:03:26 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.64.3]) by phk.freebsd.dk (Postfix) with ESMTP id 047BA170E3; Sat, 2 Aug 2008 23:03:24 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m72N3OkH003229; Sat, 2 Aug 2008 23:03:24 GMT (envelope-from phk@critter.freebsd.dk) To: Bob Keyes From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 02 Aug 2008 15:09:37 -0400." Date: Sat, 02 Aug 2008 23:03:24 +0000 Message-ID: <3228.1217718204@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-security@freebsd.org Subject: Re: The BIND scandal X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2008 23:03:28 -0000 In message , Bob Keyes writes: >Until reasonable and diplomatic people are installed as the security >contacts for organizations such as FreeBSD, I will only make patches >available to me and my close friends. I can warmly recommend you read the book "Blackmailing for dummies", as I can see that you make several classical beginner mistakes in this attempt. Better luck next time. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.