lkml.org 
[lkml]   [2008]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRE: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface foron access scanning
    Date
    From
    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.

    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.


    Jon Press
    CA/HCL Internet Security Business Unit




    -----Original Message-----
    From: malware-list-bounces@dmesg.printk.net
    [mailto:malware-list-bounces@dmesg.printk.net] On Behalf Of Eric Paris
    Sent: Monday, August 04, 2008 8:33 PM
    To: Greg KH
    Cc: linux-kernel@vger.kernel.org; malware-list@lists.printk.net
    Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface
    foron access scanning

    >
    > > 9. Process exclusion
    > > --------------------
    > > Sometimes it is necessary to exclude certain processes from being
    > > intercepted. For example it might be a userspace root kit scanner
    which
    > > would not be able to find root kits if access to them was blocked by
    the
    > > on-access scanner.
    > >
    > > To facilitate that we have created a special file a process can open
    and
    > > register itself as excluded. A flag is then put into its kernel
    > > structure (task_struct) which makes it excluded from scanning.
    > >
    > > This implementation is very simple and provides greatest
    performance. In
    > > the proposed implementation access to the exclusion device is
    controlled
    > > though permissions on the device node which are not sufficient. An
    LSM
    > > call will need to be made for this type or access in a later patch.
    >
    > Heh, so if you want to write a "virus" for Linux, just implement this
    > flag. What's to keep a "rogue" program from telling the kernel that
    all
    > programs on the system are to be excluded?

    Processes can only get this flag one of 2 ways.

    1) register as a client to make access decisions
    2) echo 1 into the magic file to enable the flag for themselves

    A process can only set this flag on itself and having this flag only
    means that your opens and closes will not be scanned. And excluded
    program could write a virus and it would not be caught on close, but it
    would be caught on the next open.




    \
     
     \ /
      Last update: 2008-08-05 17:01    [W:0.024 / U:0.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site