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

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

Date:	Wed, 6 Aug 2008 09:20:25 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Peter Dolding <oiaohm@...il.com>
Cc:	Eric Paris <eparis@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>,
	"Press, Jonathan" <Jonathan.Press@...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

Quoting Peter Dolding (oiaohm@...il.com):
> On Wed, Aug 6, 2008 at 11:55 PM, Eric Paris <eparis@...hat.com> wrote:
> > 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.
> >
> Simplely they are following the windows way of doing things.  Rootkit
> the OS no one will stop us.  Sorry that RootKitting is not going to
> work here long term because we will fix Root Kit weaknesses.  TPM from
> IBM will make it even harder.  Nice bits of that are in 2.6.27.
> 
> Allowing LSM stacking solves nothing.   IBM's developers credentials

Seriously, it's David Howells at Redhat who's doing that.  In your last
email i figured it was a typo, but credit where it's due :)

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