Messages in this thread | | | Subject | RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface foron access scanning | Date | Tue, 5 Aug 2008 10:41:44 -0400 | From | "Press, Jonathan" <> |
| |
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.
| |