linux-kernel - Re: TALPA - a threat model? well sorta.

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.DEB.1.10.0808141821150.13400@asgard.lang.hm>
Date:	Thu, 14 Aug 2008 18:31:03 -0700 (PDT)
From:	david@...g.hm
To:	Arjan van de Ven <arjan@...radead.org>
cc:	Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
	malware-list@...ts.printk.net, andi@...stfloor.org,
	riel@...hat.com, greg@...ah.com, tytso@....edu,
	viro@...IV.linux.org.uk, alan@...rguk.ukuu.org.uk,
	peterz@...radead.org, hch@...radead.org
Subject: Re: TALPA - a threat model?  well sorta.

On Wed, 13 Aug 2008, Arjan van de Ven wrote:

> 2) We very likely should have a mechanism for a userspace app to
> request a scan on a file, both sync or async (O_SYNC flag?). This is
> useful regardless because it allows the source of many things to do the
> right thing.
> 3) we need a mechanism in the kernel to track "scanned with generation
> X of signatures" that invalidates on any dirty operation. The syscall
> from 2) will use this as a cache to be quick.
>
> I think few people will disagree about this.
>
> Open questions now are
> 4) do we have the kernel kick off an async scan in open() or do we have
> glibc do this

the kernel should not kick off a scan, instead it should check to see 
an open/read should not kick off a scan, instead it should check to see if 
the scan generation tag(s) are current should be enough (remember, you may 
have more then one type of scanner running on the system)

> 5) do we have the kernel do the sync scan on read/mmap/.. or do we have
> glibc do this

definantly not the kernel. the intent of this is to keep linux from being 
a storage repository for malware used by other systems. there is no need 
to penalize linux-only apps by making them wait for a scan to take place. 
If it lives in glibc there should be a way for linux apps that know that 
they will not be exporting files to other systems to tell the library not 
to do a scan.

for example, why should a log analysis program looking at apache logs be 
forced to wait while multiple 'virii scanners' go through several gigs of 
logs before it can start looking at them.

you are going to need some way to bypass the checks anyway so that you can 
avoid the recursive case of the scanners triggering scans on files that 
they open.

by keeping the scans all in userspace it also simplifies things greatly. 
All the kernel should do is to maintain the tags with the file (posix 
attributes??) and have a mechanism to clear them when the file is dirtied.

> I think this is where the whole debate is about now.
>
> And a few hard ones
> 6) how do we deal with multiple scanning agents in parallel

not a problem, in fact multiple agents scanning in parallel is a good 
thing, it lets them all see the data with one pass through the disk.

they will all need to set different tags anyway (the fact that agent1 
blessed the data doesn't mean that it's safe if agent2 hasn't done so)

> 7) how do we prevent malware from pretending to be a virus scanner

this is not part of the threat model.

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/