linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning

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: <20080805202621.GA27489@kroah.com>
Date:	Tue, 5 Aug 2008 13:26:21 -0700
From:	Greg KH <greg@...ah.com>
To:	"Press, Jonathan" <Jonathan.Press@...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

On Tue, Aug 05, 2008 at 04:15:32PM -0400, Press, Jonathan wrote:
> On Tue, Aug 05, 2008 at 02:34:26PM -0400, Press, Jonathan wrote:
> > You're right...I am not talking about blocking at all -- which may be
> a
> > further indication that I am missing the specific point of this
> thread.
> > 
> > But be that as it may...  I don't want to have to use more than one
> > interface to get all the events I am interested in.  I want to
> register
> > as a client and listen, and get everything I need from the same place.
> 
> That's an implementation issue, not a requirement.  If it's a
> requirement, it sure is a lazy one :)
> 
> 
> [JON PRESS]  I wouldn't call it lazy, actually.  It's more like
> "economical" or "ergonomic" -- or, dare I say it -- "user-friendly."  In
> this case, the users are the AV vendors who will have to write to the
> API that will come out of this spec.  We will be more inclined to
> appreciate the SDK (for want of a better term) if it covers all the
> bases, rather than force us to go elsewhere for some of our
> requirements.  When we write SDKs, we try to make sure that our users
> will find whatever they need.

But realize that you are adding an overhead on us, the kernel community,
to make your life easier.  We are the ones that are taking our time to
review and comment on this code.  We are the ones who will have to live
with this code for forever, and maintain it over the lifetime of linux.
So far, you all have shown no willingness to give anything back to us at
all.

In fact, I'd go so far as to say you have been openly hostile, violating
our copyright and license by shipping closed source kernel modules,
making our users have huge problems when we can not support them if they
happen to have the misfortune of using your product, and creating code
that pokes directly into the kernel in ways we explicily do not want to
have happen (syscall hooking, walking symbol tables, etc.)

So please remember, that you should be the ones going out of your way to
be nice to us, as you are coming from a huge deficit here that you all
need to make up from.

> > Also, it seems to me that for my purposes, close is discrete enough.
> It
> > tells me that there is now something out there that should be looked
> at.
> 
> So, if you hook glibc to catch all calls to close, is that sufficient?
> 
> [JON PRESS]  Let's see...I'm going to use inotify for some events, glibc
> for others, and this API for the rest.  Would you really want to write
> an application like that?

Think of it as a way to justify your huge prices :)

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/