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:	Tue, 05 Aug 2008 11:01:59 +0800
From:	Cliffe <cliffe@...net>
To:	Casey Schaufler <casey@...aufler-ca.com>
CC:	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

If we had stackable LSMs then the required functionality could simply be 
built into the LSM interface. Then the anti-malware would simply stack 
itself with other LSMs. In my opinion this is a perfect example for the 
argument of stackable LSMs. So far we mainly have LSMs which provide an 
extra access control mechanism (in addition to DAC). IMHO, Ideally DAC 
could be another stackable LSM (enabled by default). 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.

Additional infrastructure would be necessary. Permissible security 
remains a item of contention. Perhaps I am naive but I think most LSMs 
could work based on accept/reject. Where every LSM must accept an action 
in order for it to be carried out.

MHO,

Cliffe.

Casey Schaufler wrote:
> Eric Paris wrote:
>> Please contact me privately or (preferably the list) for questions,
>> comments, discussions, flames, names, or anything.  I'll do complete
>> rewrites of the patches if someone tells me how they don't meet their
>> needs or how they can be done better.  I'm here to try to bridge the
>> needs (and wants) of the anti-malware vendors with the technical
>> realities of the kernel.  So everyone feel free to throw in your two
>> cents and I'll try to reconcile it all.  These 5 patches are part 1.
>> They give us a working able solution.
>>
>> >From my point of view patches forthcoming and mentioned below should
>> help with performance for those who actually have userspace scanners but
>> also could presents be implemented using this framework.
>>
>>   
>
> The LSM list (CCed) should be included in this discussion.
>> Background
>> ...
>
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
--
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/