From: Gianni Tedesco <gianni@scaramanga.co.uk>
To: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: fireflier firewall userspace program doing userspace packet filtering
Date: Mon, 30 Aug 2004 20:16:06 +0100 [thread overview]
Message-ID: <1093893366.7064.176.camel@sherbert> (raw)
In-Reply-To: <20040830181519.GE8382@lkcl.net>
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
next prev parent reply other threads:[~2004-08-30 19:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-30 10:42 fireflier firewall userspace program doing userspace packet filtering Luke Kenneth Casson Leighton
2004-08-30 18:15 ` Luke Kenneth Casson Leighton
2004-08-30 19:16 ` Gianni Tedesco [this message]
2004-08-30 20:00 ` Luke Kenneth Casson Leighton
2004-08-31 9:27 ` Luke Kenneth Casson Leighton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1093893366.7064.176.camel@sherbert \
--to=gianni@scaramanga.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=lkcl@lkcl.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.