[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <p738x4i9nyd.fsf@crumb.suse.de>
Date: 28 Nov 2007 20:20:26 +0100
From: Andi Kleen <andi@...stfloor.org>
To: "Tvrtko A. Ursulin" <tvrtko.ursulin@...hos.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: Out of tree module using LSM
"Tvrtko A. Ursulin" <tvrtko.ursulin@...hos.com> writes:
> We here at Sophos (the fourth largest endpoint security vendor in the world)
> have such a module called Talpa which is a part of our main endpoint security
> product
What is a "endpoint security product" exactly? A gateway that scans
files passing through it?
> In essence, what our module does is it intercepts file accesses and allows
> userspace daemons to vet them.
I suspect the only good way forward would be to collect the
requirements of your user space and then define a proper official
interface to do what they want to do. Ideally would be a shared proposal
from multiple groups who are doing this, e.g. if you could talk to
some others doing similar things that would be best.
Personally I admit I never quite saw the point of intercepting all
file accesses for everything. That will just always be slow as often
demonstrated on other operating systems and racey and unreliable too.
And at least the internal daemons should be already reasonably well
protected by standard (or beyond standard, like AA/SELinux etc.)
security measures, so e.g. it does not really make sense to intercept
all of your /etc file accesses and similar.
It might be better to identify the services (gateway, samba, file
server whatever) that are actually dealing with possible infected
"external" files and then define some generic interface that would
allow you to check those as the data appears.
I would expect such an approach to perform better in the end and be more
reliable too.
Note such a interface might well be user space only.
-Andi
-
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