From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S267563AbUH3KbW (ORCPT ); Mon, 30 Aug 2004 06:31:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267626AbUH3KbW (ORCPT ); Mon, 30 Aug 2004 06:31:22 -0400 Received: from open.hands.com ([195.224.53.39]:46311 "EHLO open.hands.com") by vger.kernel.org with ESMTP id S267563AbUH3Kas (ORCPT ); Mon, 30 Aug 2004 06:30:48 -0400 Date: Mon, 30 Aug 2004 11:42:02 +0100 From: Luke Kenneth Casson Leighton To: linux-kernel@vger.kernel.org Subject: fireflier firewall userspace program doing userspace packet filtering Message-ID: <20040830104202.GG3712@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-hands-com-MailScanner-SpamScore: s X-MailScanner-From: lkcl@lkcl.net Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org hi, this message is probably directed at catching rusty's attention (hi rusty) but anyone who is able to help, assistance much appreciated. please reply cc as i ain't subscribing to lkml! background: i find only _one_ firewall program [in debian] that is capable of doing firewall on-demand "popup" rule creation and packet filtering, it's called "fireflier". this also the _only_ program that i know of that also does user-space packet filtering. in other words, not only can fireflier allow you to create rules as-and-when packets come in or out (and they are queued/blocked until they are "approved") but also it allows you to create firewall rules on a PER-PROGRAM basis. which is very cool, and i don't see _any_ other firewall program doing that - for linux. [if anyone knows of any such MATURE AND STABLE userspace firewall programs with the same capability as fireflier please do let me know because the questions stop] with that background in mind, here is the problem: fireflier's "per-program" userspace packet filtering is very basic: it contains NO state-based filtering. none. zip. nada. therefore, when a program dies, the "pid" of the program, which is part of the rule, becomes lost, such that FIN ACK and RST packets get thrown to the queue... and consequently to the user, because you can be certain that there will not have been a RST or FIN ACK firewall rule created!!! with the background and the problem in mind, here is the question: is it possible to leverage - and i mean without cut/pasting large parts of kernel-space code into fireflier-in-userspace - the EXISTING kernel's iptables functionality in some way, such that per-program packet filtering may be performed? i don't actually care whether code is moved into kernel (100 lines), i don't care if code is added in userspace (100 lines). what i am looking for is a QUICK way to, say... leverage an existing API in the kernel, add one extra field (a pid) to the kernel as a hack, add a callback and a void* to the ip tracking structures as an "extra packet check" as a hack, that sort of thing, where the userspace callback gets its original void* plus the packet handed to it. the last thing i want is to cut/paste several man-years of code from the kernel to user-space - things like ip_conntrack. ultimate aim: to be able to "enhance" existing iptables firewall rule checking rather than to be backed into a corner of "replacing" existing functionality.... just because of one extra check [the pid] l. -- -- Truth, honesty and respect are rare commodities that all spring from the same well: Love. If you love yourself and everyone and everything around you, funnily and coincidentally enough, life gets a lot better. -- lkcl.net
lkcl@lkcl.net
From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268848AbUH3SYv (ORCPT ); Mon, 30 Aug 2004 14:24:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268838AbUH3SYX (ORCPT ); Mon, 30 Aug 2004 14:24:23 -0400 Received: from open.hands.com ([195.224.53.39]:61070 "EHLO open.hands.com") by vger.kernel.org with ESMTP id S268724AbUH3SEP (ORCPT ); Mon, 30 Aug 2004 14:04:15 -0400 Date: Mon, 30 Aug 2004 19:15:20 +0100 From: Luke Kenneth Casson Leighton To: linux-kernel@vger.kernel.org Subject: Re: fireflier firewall userspace program doing userspace packet filtering Message-ID: <20040830181519.GE8382@lkcl.net> References: <20040830104202.GG3712@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040830104202.GG3712@lkcl.net> User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-hands-com-MailScanner-SpamScore: s X-MailScanner-From: lkcl@lkcl.net Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org regarding this issue, i have done some exploration and found that ipt_owner is capable of registering by pid. therefore, the naive approach considered was to have fireflier "vet" rules via its userspace rules dynamically creating per-pid _new_ and _real_ rules (based on the template of options specified from the corresponding userspace rule) but of course with the ipt_owner "pid" set. this would at first glance solve the "INCOMING" problem which i understand the present ipt_owner code to be suffering from. anyway - this approach is insufficient and fraught with difficulties, not least involving purging the queue of existing packets that _would_ match the newly created rule, but it's too late, they're already in the queue. etc. so, what i would like to consider doing is to modify the ipt_owner module to include the full pathname of the binary it is supposed to vet. i don't give a rat's monkeybutt about "oo, yuk, that's disgusting to do that in the kernel" or "that would _so_ slow network traffic down": i don't care: this is going in an selinux system where the performance hit of selinux has already been accepted, so a couple more percentage performance hit i really don't give a stuff. so, my question, therefore, is: what should i record in a modified version of ipt_owner in order to "vet" packets on a per-executable basis? should i consider recording the inode of the program's binary? should i consider recording the _name_ of the program? if i record the inode number, what example code should i examine in order to DoTheRightThing of getting from process-pid to inode/program? for example, i notice in ipt_owner.c that match_pid() calls find_task_by_pid(). okkkaaay... so... and then in fs/proc/base.c's proc_exe_link(), i see that get_task_mm() is called to get something called an mm_struct. and theeeennn... dget is called on _that_, and _then_ in struct dentry, there's something called a d_inode, and _that_ is what i presume contains the inode number of the running process (i_ino). am i along the right lines, or should i be (according to proc_exe_link()) hunting down the struct vfsmount argument with mntget() instead? somehow i don't think so, but i haven't any point of reference to know in advance. anyone with experience in the workings of proc and things, your input and advice greatly appreciated. l. On Mon, Aug 30, 2004 at 11:42:02AM +0100, Luke Kenneth Casson Leighton wrote: > is it possible to leverage - and i mean without cut/pasting > large parts of kernel-space code into fireflier-in-userspace - > the EXISTING kernel's iptables functionality in some way, > such that per-program packet filtering may be performed? > ultimate aim: > > to be able to "enhance" existing iptables firewall rule > checking rather than to be backed into a corner of "replacing" > existing functionality.... just because of one extra check > [the pid] From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268271AbUH3TSK (ORCPT ); Mon, 30 Aug 2004 15:18:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268275AbUH3TSK (ORCPT ); Mon, 30 Aug 2004 15:18:10 -0400 Received: from trantor.org.uk ([213.146.130.142]:8934 "EHLO trantor.org.uk") by vger.kernel.org with ESMTP id S268271AbUH3TR6 (ORCPT ); Mon, 30 Aug 2004 15:17:58 -0400 Subject: Re: fireflier firewall userspace program doing userspace packet filtering From: Gianni Tedesco To: Luke Kenneth Casson Leighton Cc: linux-kernel@vger.kernel.org In-Reply-To: <20040830181519.GE8382@lkcl.net> References: <20040830104202.GG3712@lkcl.net> <20040830181519.GE8382@lkcl.net> Content-Type: text/plain Date: Mon, 30 Aug 2004 20:16:06 +0100 Message-Id: <1093893366.7064.176.camel@sherbert> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2004-08-30 at 19:15 +0100, Luke Kenneth Casson Leighton wrote: > so, my question, therefore, is: > > what should i record in a modified version of ipt_owner in > order to "vet" packets on a per-executable basis? > > should i consider recording the inode of the program's binary? Bear in mind that that would make sense for an ACCEPT rule, but for a DROP rule, copying the binary would bypass the check. > should i consider recording the _name_ of the program? And bear in mind any user can set the name (I assume you mean the argv [0] here) of their process to whatever they like, and then use the firewall rules for another program. Maybe cryptographically checksumming all the executable file-backed maps would be closer to what you want. This ensures that the code you "trust" to do the right-thing(tm) on the network is the only code that can generate/receive whatever traffic. That approach has it's own issues though too. > for example, i notice in ipt_owner.c that match_pid() calls > find_task_by_pid(). okkkaaay... so... and then in fs/proc/base.c's > proc_exe_link(), i see that get_task_mm() is called to get > something called an mm_struct. and theeeennn... dget is called > on _that_, and _then_ in struct dentry, there's something called > a d_inode, and _that_ is what i presume contains the inode number > of the running process (i_ino). Firewalling on PID has rather obvious security ramifications, unless the PID is 0 or 1. > am i along the right lines, or should i be (according to > proc_exe_link()) hunting down the struct vfsmount argument > with mntget() instead? somehow i don't think so, but i haven't > any point of reference to know in advance. Using paths to exec'ed binaries has problems too, as we have per-process namespaces etc.. I've seen no evidence that any existing firewall software has got this functionality right thus far. HTH. -- // Gianni Tedesco (gianni at scaramanga dot co dot uk) lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import 8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268950AbUH3TxG (ORCPT ); Mon, 30 Aug 2004 15:53:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268886AbUH3Twj (ORCPT ); Mon, 30 Aug 2004 15:52:39 -0400 Received: from open.hands.com ([195.224.53.39]:63390 "EHLO open.hands.com") by vger.kernel.org with ESMTP id S268896AbUH3TtN (ORCPT ); Mon, 30 Aug 2004 15:49:13 -0400 Date: Mon, 30 Aug 2004 21:00:23 +0100 From: Luke Kenneth Casson Leighton To: Gianni Tedesco Cc: linux-kernel@vger.kernel.org Subject: Re: fireflier firewall userspace program doing userspace packet filtering Message-ID: <20040830200023.GA31497@lkcl.net> References: <20040830104202.GG3712@lkcl.net> <20040830181519.GE8382@lkcl.net> <1093893366.7064.176.camel@sherbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1093893366.7064.176.camel@sherbert> User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-hands-com-MailScanner-SpamScore: s X-MailScanner-From: lkcl@lkcl.net Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 30, 2004 at 08:16:06PM +0100, Gianni Tedesco wrote: > On Mon, 2004-08-30 at 19:15 +0100, Luke Kenneth Casson Leighton wrote: > > so, my question, therefore, is: > > > > what should i record in a modified version of ipt_owner in > > order to "vet" packets on a per-executable basis? > > > > should i consider recording the inode of the program's binary? > > Bear in mind that that would make sense for an ACCEPT rule, but for a > DROP rule, copying the binary would bypass the check. i understand! i thought that selinux by default would stop me from being able to copy binaries from /usr/bin.... uhn... no such luck. if it becomes an issue i will investigate removing read access! > > should i consider recording the _name_ of the program? > > And bear in mind any user can set the name (I assume you mean the argv > [0] here) of their process to whatever they like, and then use the > firewall rules for another program. so, inode it is. > Maybe cryptographically checksumming all the executable file-backed maps > would be closer to what you want. This ensures that the code you "trust" > to do the right-thing(tm) on the network is the only code that can > generate/receive whatever traffic. That approach has it's own issues > though too. i should imagine that at some point down the line, selinux would be of some assistance here. > > for example, i notice in ipt_owner.c that match_pid() calls > > find_task_by_pid(). okkkaaay... so... and then in fs/proc/base.c's > > proc_exe_link(), i see that get_task_mm() is called to get > > something called an mm_struct. and theeeennn... dget is called > > on _that_, and _then_ in struct dentry, there's something called > > a d_inode, and _that_ is what i presume contains the inode number > > of the running process (i_ino). > > Firewalling on PID has rather obvious security ramifications, unless the > PID is 0 or 1. > > > am i along the right lines, or should i be (according to > > proc_exe_link()) hunting down the struct vfsmount argument > > with mntget() instead? somehow i don't think so, but i haven't > > any point of reference to know in advance. > > Using paths to exec'ed binaries has problems too, as we have per-process > namespaces etc.. i'd be happy to set the rules by the "inode" of the program, and to have a userspace program do a lookup (at startup time) of the inode of the various programs, and load the rules for the appropriate set of binaries. the only thing is of course installing new binaries, you need to reload the rules (new inodes). i could kick that idiot responsible for dpkg maintenance. russell's idea of providing /etc/dpkg/postinst.d is exactly the sort of thing that's required to re-run iptable-rule-reloading like this, and the idiot won't accept the patch. l. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S267566AbUHaJRG (ORCPT ); Tue, 31 Aug 2004 05:17:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267591AbUHaJRF (ORCPT ); Tue, 31 Aug 2004 05:17:05 -0400 Received: from open.hands.com ([195.224.53.39]:37814 "EHLO open.hands.com") by vger.kernel.org with ESMTP id S267555AbUHaJQl (ORCPT ); Tue, 31 Aug 2004 05:16:41 -0400 Date: Tue, 31 Aug 2004 10:27:51 +0100 From: Luke Kenneth Casson Leighton To: Gianni Tedesco Cc: linux-kernel@vger.kernel.org Subject: Re: fireflier firewall userspace program doing userspace packet filtering Message-ID: <20040831092751.GK31497@lkcl.net> References: <20040830104202.GG3712@lkcl.net> <20040830181519.GE8382@lkcl.net> <1093893366.7064.176.camel@sherbert> <20040830200023.GA31497@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040830200023.GA31497@lkcl.net> User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-hands-com-MailScanner-SpamScore: s X-MailScanner-From: lkcl@lkcl.net Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 30, 2004 at 09:00:23PM +0100, Luke Kenneth Casson Leighton wrote: > On Mon, Aug 30, 2004 at 08:16:06PM +0100, Gianni Tedesco wrote: > > On Mon, 2004-08-30 at 19:15 +0100, Luke Kenneth Casson Leighton wrote: > > > so, my question, therefore, is: > > > > > > what should i record in a modified version of ipt_owner in > > > order to "vet" packets on a per-executable basis? > > > > > > should i consider recording the inode of the program's binary? > > > > Bear in mind that that would make sense for an ACCEPT rule, but for a > > DROP rule, copying the binary would bypass the check. > > i understand! > > i thought that selinux by default would stop me from being > able to copy binaries from /usr/bin.... uhn... no such luck. > > if it becomes an issue i will investigate removing read access! okay. first thing: 1) assuming that the DROP rule issue is one that cannot be avoided, and that a rules design policy of "deny everything and only allow specifics" is required, then checking on the _full_ pathname of the program is required. second thing: 2) it _is_ possible to hunt through the selinux policy macros to remove the execute permission on binaries that a user drops into their home directory, or copies into their home directory. l. -- -- Truth, honesty and respect are rare commodities that all spring from the same well: Love. If you love yourself and everyone and everything around you, funnily and coincidentally enough, life gets a lot better. -- lkcl.net
lkcl@lkcl.net