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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2629CC4E1D22A64593B02C43E85553030480743F@USILMS12.ca.com>
Date:	Tue, 5 Aug 2008 14:38:23 -0400
From:	"Press, Jonathan" <Jonathan.Press@...com>
To:	"Greg KH" <greg@...ah.com>
Cc:	"Arjan van de Ven" <arjan@...radead.org>,
	"Eric Paris" <eparis@...hat.com>, <linux-kernel@...r.kernel.org>,
	<malware-list@...ts.printk.net>,
	<linux-security-module@...r.kernel.org>
Subject: RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning

>> I think you might be missing the point a bit here, as the traditional
Unix model that 
>> Linux has prevents much of what the "traditional AV" products need to
do, right?

Is your point that Linux and Unix machines are less vulnerable to
viruses?  If so, that's not relevant to my point at all.  A Unix machine
can be a carrier, passing infections on to other vulnerable platforms
(guess which one).  An enterprise security system sees the entire
enterprise as an integrated whole -- not just individual machines with
their own separate attributes and no impact on each other at all.


>>So how are you going about preventing the "infection from arriving"
>> with this proposed patchset?

I'm not endorsing or opposing the proposal until I digest it further.

However, I will say that while preventing infections from arriving is
not foolproof, doing a scan-on-close with the option to delete or
quarantine an infected file goes a long way.


Jon





-----Original Message-----
From: Greg KH [mailto:greg@...ah.com] 
Sent: Tuesday, August 05, 2008 2:12 PM
To: Press, Jonathan
Cc: Arjan van de Ven; Eric Paris; linux-kernel@...r.kernel.org;
malware-list@...ts.printk.net; linux-security-module@...r.kernel.org
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a
linuxinterfaceforon access scanning


A: No.
Q: Should I include quotations after my reply?

On Tue, Aug 05, 2008 at 02:04:26PM -0400, Press, Jonathan wrote:
> I'm not sure if this is off the direct idea of this thread, or if I am
> possibly missing the whole point.

I think you might be missing the point a bit here, as the traditional
Unix model that  Linux has prevents much of what the "traditional AV"
products need to do, right?

> However, I want to point out that scanning on close is still an
integral
> part of AV protection, even if intercepting opens and execs
> theoretically catches everything.

Great, then put a hook in glibc and catch all closes and then kick off
your scanning.

> You can say that there are four parts to the malware life cycle --
> getting on a machine, residing there, causing local damage, and
> propagating elsewhere.  It is part of the philosophy of AV protection
> that you do everything you can to prevent all of them.

But this proposed patchset does not do much to prevent all of these,
right?

> That's why there are scans on close, scheduled scans, and scans on
> open.  Most of our users employ all three and do not rely on one or
> two.  If an infection arrives on a machine and finds a home because it
> is assumed that it will be caught when it is opened for use, then it
> is just one more compromise away from doing damage and/or spreading.

So how are you going about preventing the "infection from arriving" with
this proposed patchset?

Isn't that something that SELinux or another LSM can prevent better?

thanks,

greg k-h

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ