From: Jonathan Day <imipak@yahoo.com>
To: Peter Dolding <oiaohm@gmail.com>
Cc: rmeijer@xs4all.nl, Casey Schaufler <casey@schaufler-ca.com>,
Samir Bellabes <sam@synack.fr>,
linux-security-module <linux-security-module@vger.kernel.org>,
Stephan Peijnik <stephan@peijnik.at>,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"
Date: Thu, 22 Jan 2009 09:08:04 -0800 (PST) [thread overview]
Message-ID: <5807.2433.qm@web31502.mail.mud.yahoo.com> (raw)
In-Reply-To: <e7d8f83e0901220546l90987a7ic3d7a7c98b14f07a@mail.gmail.com>
--- On Thu, 1/22/09, Peter Dolding <oiaohm@gmail.com> wrote:
(snip)
> Worked with IPv4/6 hardware stacks. Most of ones I have
> handled have
> had built in firewall processing. Letting them feed
> directly into
> userspace becomes very uncontrollable very quickly.
> Netfilter can be
> altered to operate like ALSA with hardware mixer. Yes
> slower but you
> can filter. Doing it at LSM you still have to place it in
> middle.
> Big issue with IPv4/6 hardware direct feeding into user
> space you have
> to get in middle to apply any forms of filters anyhow.
Ok, the LSM argument is certainly true, the direct feed I can see, and the ALSAfication of filtering is a highly intriguing solution that does answer the questions I had. From where I'm sitting (and I have no idea whatsoever whether that's remotely close to where anyone else sits), you've made a convincing argument.
(snip)
> Its not a completely different set of problems. Please
> stop trying
> to draw lines in the sand between different groups. Most
> critical
> thing for a firewall is that it works.
You'll get no argument from me on that.
(snip)
> Its just like the old idea that realtime OS's have
> nothing the same
> with supercomputers. It turns out they have a lot in
> common lot of
> alterations to improve realtime support in Linux has
> increased
> supercomputer though put massively.
There, I 100% agree. Having worked for a supercomputer startup, I went through the bouncing-rocks-off-heads stage of getting people to see realtime and high-performance were not mutually-exclusive and did indeed have a lot in common.
> Desktop User needs a firewall that works correctly.
> Server
> Administrators need the same. Server Administrators do
> want simple
> to configure and be sure the firewall is right. Same with
> Desktop
> users.
Again, you'll get no argument from me on that.
> When you get right down to it there is no much difference.
You've convinced me.
(snip)
> Linux network stack was very much designed with these evils
> in mind.
> Its highly modular it is the only way you can take this
> problem on.
> No matter what there will be events where you need to
> change the
> processing path completely by being modular you can.
> These
> corner-cases are some of the reason why I keep on saying
> LSM is not
> the place. Worst nightmares of the some of the
> corner-cases where
> some applications need treatment by a completely different
> processing
> stack to everything else. LSM does not allow loading two
> modules/more
> safely without risking standing on the other LSM toes.
>
> Basically if you cannot load multiable and assign them to
> different
> applications the design is not going to cut it in some of
> the corner
> cases. Realtime vs Normal is fun enough.
This is probably the part of the argument that really made the case for me, as it covers both the weird paths problem and the modularity you need to make sure everything does get covered. The "everything gets covered" problem is the toughest part of any kind of access control on sockets and having gone hunting for as many weird and wonderful networking patches, I've seen some truly strange stuff.
> With clusters and shipping applications between processes
> supporting
> it gets a little pain in but. Most likely putting the
> information in
> task credentials would be the sane solution then have when
> application
> is sent between machines its task credentials go with it.
Yes, it is a pain, and that makes it an excellent test. Almost anyone can write code that works under the most mainstream of normal conditions, so those simply aren't that useful in telling different methods apart. Things get fun when you start looking around the fringes, because that's when you really get an idea for when something can be readily extended or is going to be hitting a brick wall.
(snip)
It seems to me that the netfilter proponents have managed to solve everything I've thrown in their direction and have raised some good points regarding LSM. (And apologies if any of my prior posts got on anyone's nerves. I tend to be good at that.) This looks like it's going to be a fascinating and very well-argued debate, which can only be good news for whatever Linux ends up with.
Jonathan Day
next prev parent reply other threads:[~2009-01-22 17:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-21 9:32 RFC: Mandatory Access Control for sockets aka "personal firewalls" Rob Meijer
2009-01-21 23:28 ` Peter Dolding
2009-01-22 0:50 ` Jonathan Day
2009-01-22 0:59 ` Casey Schaufler
2009-01-22 6:29 ` Jonathan Day
2009-01-22 13:46 ` Peter Dolding
2009-01-22 17:08 ` Jonathan Day [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-01-21 7:25 Rob Meijer
2009-01-21 8:15 ` Peter Dolding
2009-01-21 8:35 ` Jan Engelhardt
2009-01-20 17:48 Stephan Peijnik
2009-01-20 18:24 ` Jan Engelhardt
2009-01-20 18:56 ` Stephan Peijnik
2009-01-20 20:15 ` Samir Bellabes
2009-01-20 20:31 ` Jan Engelhardt
2009-01-20 20:53 ` Paul Moore
2009-01-20 21:42 ` Samir Bellabes
2009-01-20 21:51 ` Paul Moore
2009-01-20 19:46 ` Jonathan Day
2009-01-20 21:01 ` Paul Moore
2009-01-21 0:54 ` Samir Bellabes
2009-01-21 1:18 ` Casey Schaufler
2009-01-21 3:14 ` Samir Bellabes
2009-01-20 20:47 ` Paul Moore
2009-01-20 23:48 ` Stephan Peijnik
2009-01-21 8:18 ` Samir Bellabes
2009-01-21 14:49 ` Paul Moore
2009-01-21 0:40 ` Samir Bellabes
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=5807.2433.qm@web31502.mail.mud.yahoo.com \
--to=imipak@yahoo.com \
--cc=casey@schaufler-ca.com \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=oiaohm@gmail.com \
--cc=rmeijer@xs4all.nl \
--cc=sam@synack.fr \
--cc=stephan@peijnik.at \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).