linux-kernel - Re: [malware-list] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.DEB.1.10.0808142145050.12859@asgard.lang.hm>
Date:	Thu, 14 Aug 2008 21:48:53 -0700 (PDT)
From:	david@...g.hm
To:	Theodore Tso <tytso@....edu>
cc:	Christoph Hellwig <hch@...radead.org>,
	Eric Paris <eparis@...hat.com>, tvrtko.ursulin@...hos.com,
	alan@...rguk.ukuu.org.uk, andi@...stfloor.org,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	malware-list-bounces@...sg.printk.net, peterz@...radead.org,
	viro@...IV.linux.org.uk
Subject: Re: [malware-list] TALPA - a threat model?  well sorta.

On Thu, 14 Aug 2008, Theodore Tso wrote:

> On Thu, Aug 14, 2008 at 06:44:33PM -0700, david@...g.hm wrote:
>> could you do something like defining a namespace inside posix attributes
>> and then setting up a mechanism in the kernel to alert if the attributes
>> change (with the entire namespace getting cleared if the file gets
>> dirtied)?
>
> According to Eric Paris the clean/dirty state is only stored in
> memory.  We could use the extended attribute interface as a way of not
> defining a new system call, or some other interface, but I'm not sure
> it's such a great match given that the extended attributes interface
> are designed for persistent data.
>
> I agree that doesn't actually work very well for the tracker use case,
> where you the clean/dirty bit to be persistent (in case the tracker is
> disabled due to the fact you are running on battery, for example, and
> then you reboot).

why would you not want the results of the viris scan to be persistant?

assuming that you are not dual-booting( or otherwise taking explicit 
action to go around the OS), the fact that you scanned the file with 
signature set 123 is just as valid now as it was yesterday.

If you are not trying to work around the actions of root, why are you 
trying to work around the actions of the person who has physical control 
of the system? (who could easily become root if they wanted to)

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/