linux-kernel - RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface foron 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 10:56:52 -0400
From:	Eric Paris <eparis@...hat.com>
To:	"Press, Jonathan" <Jonathan.Press@...com>
Cc:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	malware-list@...ts.printk.net
Subject: RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface
	foron access scanning

On Tue, 2008-08-05 at 10:41 -0400, Press, Jonathan wrote:
> I share the concern here.  The idea that a piece of malware can exclude
> itself seems nasty to me.  I am not an expert on writing malware, but it
> intuitively seems to me to be a huge opportunity for creativity.  The
> argument that it's ok because anything that the malware writes will
> eventually be scanned anyway does not reassure me.

You aren't doing write time scanning anyway.  This exclusion means that
an 'excluded' process can OPEN things that would normally be called
malware.  The model here doesn't talk about adding files with bad
information to the system it talks about stopping that bad information
from being opened and propagated further.  Thread exclusions as they are
written in the patch only weaken security to those processes which
actively choose to read malware, it in no way weakens the security of
the system as a whole...
> 
> Also...  I was one of the people who brought up the idea of a process
> exclusion when the requirements list was being developed.  I intended it
> as a way that an AV application could exclude specific OTHER processes
> by name (as selected by the AV user) -- not as a way that a process
> would exclude itself.  I don't think that the implementation here
> reflects this goal, which still seems to me to be a requirement.

Wait wit, you'd rather have a 'privileged' process be allowed to exclude
every other process on a system than have a it only be allowed to
exclude itself? and somehow that is safer?

"by name" is right out the window.  You are never going to win 'by name'
on anything to do with the kernel  :)  Maybe you can get me to
eventually buy into 'by pid' or something like that, but setting flags
on other running processes is always going to be racy and scary for me.
Can you show me some code on how to do this cleanly?  And why it needs
to be done in kernel?

What is the goal you are trying to achieve?  A performance win for the
application in question or is this a security aware application that
needs to be able to access 'sensitive' data?

-Eric

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