linux-kernel - Re: [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Aug 2008 10:18:06 -0400
From:	Paul Moore <paul.moore@...com>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Cliffe <cliffe@...net>, Eric Paris <eparis@...hat.com>,
	malware-list@...ts.printk.net, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: Re: [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning

On Tuesday 05 August 2008 11:00:31 pm Casey Schaufler wrote:
> 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.

I still don't understand how that is any different from a file or some 
other resource, local or remote.  Assuming a single security label 
(tag, mark, mode, etc.) on an entity on which you wish to apply an 
access control decision the problem boils down to how do you 
internalize the security label in such a way that it can be useful for 
the security mechanism(s).  In the case of a single LSM you do this 
once, in the case of multiple, stacked LSMs you do this multiple times.

With multiple security markings on an entity then you have to decide if 
you want to consider every marking at each LSM instance, or a subset.  
The complexity in this case does go up dramatically, but I think the 
key point for our discussion is that it doesn't matter if the entity is 
a file or a packet.

> 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.

Once again, these points apply equally to files as they do to packets.

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