linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon 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:	Fri, 15 Aug 2008 10:31:33 -0700 (PDT)
From:	david@...g.hm
To:	Peter Dolding <oiaohm@...il.com>
cc:	rmeijer@...all.nl, Alan Cox <alan@...rguk.ukuu.org.uk>,
	capibara@...all.nl, Eric Paris <eparis@...hat.com>,
	Theodore Tso <tytso@....edu>, Rik van Riel <riel@...hat.com>,
	davecb@....com, linux-security-module@...r.kernel.org,
	Adrian Bunk <bunk@...nel.org>,
	Mihai Don??u <mdontu@...defender.com>,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	Pavel Machek <pavel@...e.cz>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon
 access scanning

On Fri, 15 Aug 2008, Peter Dolding wrote:

>>> Its called SELinux and SELinux can already do this sort of stuff,
>>> including things like "only rpm may create files you are permitted to
>>> execute"
>>
>> This "permitted to execute" is what I feel is the wrong aproach with
>> respect to malware. If you simply allow everything to 'execute', I think
>> that untrusted programs may still be used for usefull things, but without
>> the potential do do malice. If you start from the point where everything
>> both trusted and untrusted  is permitted to be executed, you could make it
>> the job of SELinux or any other LSM to make untrusted code run without
>> doing malice, but with the possibility to still run and do usefull non
>> malicious  stuff. This might require some aditional hooks in LSM though I
>> could imagine.
>>
>> To take this one step further, it might be usefull to see what kernel/LSM
>> changes would be needed to allow SELinux and/or possibly better yet,
>> AppArmor, to work with some powerbox style UI component in order to both
>> allow and force untrusted programs to run with least authority and still
>> do usefull stuff.
>>
>> I feel the Polaris/Capdesk/Plash approach to untrusted code is much more
>> prommising than the "don't run" approach used by regular AV products.
>> Making such an approach integrate with LSM's would IMHO be a much more
>> fundamental approach to malware.
>>
> They way I look at this.   Most users complain that creating profiles
> for applications is too complex.
>
> Lets look for where a system that deals with the same kind of issue.
> Its in the firewall with ipset http://ipset.netfilter.org/.
>
> You have a set of rules to do things assigned in the firewall.   With
> secuirty this would be the LSM.  User gets to choose from a predefined
> list for applications without profiles.
>
> Lets look at some basics here.  Firefox and most internet applications
> don't need to edit everything in the user account.   If some link
> could be designed into LSM for user to once off approve actions
> outside filesystem permissions from the grouping.  Malware reading and
> writing stuff would be a lot harder.
>
> Major problem everyone keeps on missing.  TALPA is only operating with
> part of the full information about the file.    When file systems go
> from native file system to inodes currently the permissions on the
> native file system are translated to what linux supports and any that
> don't fit is disregarded.   Due to that difference each file system
> has its own cache and holes on the file system where viruses could
> hide data for other OS's on the system.  So TALPA might save Linux
> only to see another OS on the system infected.   Worst case is if the
> other OS infected could come back and alter Linux disabling the virus
> scanner and reinfecting Linux.

please define your threat model. the section above makes no sense with the 
currently defined threat model.

if the linux kernel squashes stuff from a filesystem such that the 
scanners cannot see it then how in the world can linux then server this 
bad stuff to other systems (what the current threat model is defined as)

if you are saying that you want linux to mount filesystems and scan them, 
then unmount them and allow other systems to mount them and be safe, I 
think you alone in this opinion.

David Lang
--
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/