lkml.org 
[lkml]   [2008]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning
    On Wed, Aug 6, 2008 at 11:55 PM, Eric Paris <eparis@redhat.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
    is a far better place for file system monitoring to hook in. Its pre
    caching allows all the alterations they could want. Even better
    credentials is a required patch to clean up Linux internal permission
    splating all over the place. Then generic filesystem caching sits on
    top of that. So 1 less cache needed. Ie the cache of passes and
    failures they keep so they don't slow the system down too much.

    About time they wake up Linux Different OS. We have zero tolerance of
    root kits. There is a section with the design to provide the file
    system monitoring and the network monitoring both without being in LSM
    space. So why do they need LSM's. Cannot they just use system LSM's
    to protect there anti-virus like everyone else. No need to treat
    them special. If they have a issue with a LSM not being good enough
    they need to speak up.

    They really need to provide what they want to do to us. There issue
    is they keep on looking in the wrong places and doing things the
    windows way. This is not WINDOWS. In time mac and other OS's could
    come tighter on root kits as well causing the programs to fail as
    well. Basically get use to working with a OS that does not tolerate
    secuirty flaws.

    Peter Dolding


    \
     
     \ /
      Last update: 2008-08-06 16:15    [W:4.645 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site