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]

Date:	Fri, 15 Aug 2008 10:47:15 -0700 (PDT)
From:	david@...g.hm
To:	"Press, Jonathan" <Jonathan.Press@...com>
cc:	Peter Zijlstra <peterz@...radead.org>,
	Helge Hafting <helge.hafting@...el.hist.no>,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	hch@...radead.org, andi@...stfloor.org, viro@...IV.linux.org.uk,
	alan@...rguk.ukuu.org.uk, Arjan van de Ven <arjan@...radead.org>
Subject: RE: [malware-list] TALPA - a threat model?  well sorta.

On Fri, 15 Aug 2008, Press, Jonathan wrote:

>> -----Original Message-----
>> From: david@...g.hm [mailto:david@...g.hm]
>>
>> On Fri, 15 Aug 2008, Press, Jonathan wrote:
>>
>>>> -----Original Message-----
>>>> From: david@...g.hm [mailto:david@...g.hm]
>>>>> The problem is that you have to account for the cases where the
> malware
>>>>> made it onto the system even if you were trying to catch it ahead
> of
>>>>> time.  For example:
>>>>>
>>>>> - Administrator turns off or reduces AV protection for some reason
> for
>>>>> some period of time.  It happens all the time.
>>>>
>>>> according to the threat model actions of the administrator do not
> matter.
>>>
>>> Sorry, I don't know what you mean.
>>
>> the threat model that was posted two days ago in the initial message
> of
>> this thread specificly stated that actions of root are not something
> that
>> this is trying to defend against.
>
> I think you may have missed the point of any such statement.
>
> Just to clarify...
>
> The model does not exclude root-owned processes from the notification
> and scanning sequence.  If root attempts to execute a file, that file
> would be scanned before the execution is allowed.  If a root-owned
> process attempts to open a file, that access would be blocked until the
> file is scanned.  If a root-owned process closes a file that has been
> written to, that file would be scanned.

correct so far.

> In addition, to generalize from the incorrect idea that the actions of
> root are not being defended against to the idea that the possible
> impacts of an administrator's actions in configuring an application
> should not be accounted for at all in our thinking doesn't make sense to
> me anyway.

questions had been raised about how this model could defend against all 
the tricky things that root can do, the answer was that they are not 
trying to defend against root doing tricky things.

turning off the scanner, letting things get infected, and turning it back 
on would fall in the same catagory as marking a file that the scanner 
marked as bad as sucessfully scanned.

in any case the vunerability is limited as the next time the signatures 
are updated the files would get scanned again, so I don't think it's a big 
problem in practice.

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/