[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080806142025.GB10274@us.ibm.com>
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/
Powered by blists - more mailing lists