Message-ID: <489913CF.1010708@schaufler-ca.com>
Date: Tue, 05 Aug 2008 20:00:31 -0700
From: Casey Schaufler <casey@schaufler-ca.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Paul Moore <paul.moore@hp.com>
CC: Cliffe <cliffe@ii.net>, Eric Paris <eparis@redhat.com>,
       malware-list@lists.printk.net, linux-kernel@vger.kernel.org,
       linux-security-module@vger.kernel.org
Subject: Re: [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning
References: <1217883616.27684.19.camel@localhost.localdomain> <4897C2A7.7020601@ii.net> <4897CC9C.2090906@schaufler-ca.com> <200808051656.28231.paul.moore@hp.com>
In-Reply-To: <200808051656.28231.paul.moore@hp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1412
Lines: 32

Paul Moore wrote:
> On Monday 04 August 2008 11:44:28 pm Casey Schaufler wrote:
>   
>> Cliffe wrote:
>>     
>>> Other security schemes such as intrusion detection,
>>> firewalls/netfilter, anti-malware, and application restrictions
>>> (sandboxes such as jails or finer grained restrictions such as
>>> AppArmor) could all register LSMs onto the stack.
>>>       
>> Stacking is easy for files. It's a real pain in the backside for UDP
>> packets.
>>     
>
> How is it any better/worse for UDP packets than files?
>   
On delivery you'd need to decide what security scheme is actually
available on the packet and in what order to interpret any inbound
security data. If you had an MLS scheme that uses CIPSO, an integrity
mechanism using IPSEC and a DAC scheme that assigns user ids by
host address getting the ordering right and every domain registered
properly in the networking stack would be a trick. Plus, making sure
that any state the security scheme requires is tricky. Maybe it's not
actually worse if the schemes agree on what qualifies as a security
element, but if one scheme does access control outbound while another
does inbound it will get hairy.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/