linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon 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]

Message-Id: <1218030956.27684.232.camel@localhost.localdomain>
Date:	Wed, 06 Aug 2008 09:55:56 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	"Press, Jonathan" <Jonathan.Press@...com>,
	Peter Dolding <oiaohm@...il.com>,
	Rik van Riel <riel@...hat.com>, Greg KH <greg@...ah.com>,
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a
	linuxinterfaceforon access scanning

On Wed, 2008-08-06 at 06:49 -0700, Arjan van de Ven wrote:
> On Wed, 6 Aug 2008 09:11:14 -0400
> > There was probably an implicit assumption on everyone's part,
> > including Red Hat's, that what ought to be done was to replace the
> > existing syscall-based event trapping with some other interface that
> > more or less does the same thing in a cleaner way -- NOT to have all
> > of the AV and other product vendors go out and completely rethink
> > their models.  And that's not because we inherently object to
> > rethinking.  It's really an issue of what kind of time frame we have
> > before a new OS goes out that completely breaks our products.
> 
> not writing to the syscall table hasn't been possible/allowed for..
> about 5 years now. (yes I know there were still bad hacks possible
> until 2 years ago). So I'm sorry, but the timeline argument doesn't
> hold, you've had 5+ years of warning.
> 
> All existing RHEL products already don't allow this (I know it for the
> earlier ones since I was part of the design team)...  unless your
> software acts entirely like a rootkit (but even then)

Other options involved overwriting LSM function pointers.  I was told
that recently moving SELinux to be statically compiled in apparently
messed them up on that method, at least for RH products.  The other
method I've heard is hunting down all of the filesystem_operations
structs and overwriting those functions.  I was also told that until
recently pages marked RO could just be marked RW and then remarked RO,
although it was recently fixed to RO pages stayed RO.  So yeah, I'd have
to call them all ugly rootkit like hacks.

they just keep finding uglier and uglier ways to infiltrate the kernel
which is why I was ask to try to help get a clean solution.

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