* security module question
@ 2009-08-04 22:06 Justin Banks
2009-08-05 2:02 ` James Morris
0 siblings, 1 reply; 4+ messages in thread
From: Justin Banks @ 2009-08-04 22:06 UTC (permalink / raw)
To: linux-kernel
Hello - I'm trying to implement a security module that will allow or
disallow writes on files by byte ranges. Is there a way to use
inode_permission() to do this, or is there an alternative route I should
take? It doesn't look like inode_permission() will give me the data I
need (offset + length of write).
Also, is there a security module that will examine data being written
for certain patterns or content?
Please CC: me on responses. I used to be subscribed, but the traffic was
just too much.
-justinb
--
Justin Banks
BakBone Software
justinb@bakbone.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: security module question
2009-08-04 22:06 security module question Justin Banks
@ 2009-08-05 2:02 ` James Morris
2009-08-06 18:38 ` Eric Paris
0 siblings, 1 reply; 4+ messages in thread
From: James Morris @ 2009-08-05 2:02 UTC (permalink / raw)
To: Justin Banks; +Cc: linux-kernel, linux-security-module, Eric Paris
On Tue, 4 Aug 2009, Justin Banks wrote:
> Hello - I'm trying to implement a security module that will allow or
> disallow writes on files by byte ranges. Is there a way to use
> inode_permission() to do this, or is there an alternative route I should
> take? It doesn't look like inode_permission() will give me the data I
> need (offset + length of write).
This doesn't seem to fit with the LSM model, where access is mediated at
object-level granularity. i.e. can user A read file B ?
> Also, is there a security module that will examine data being written
> for certain patterns or content?
The fanotify / TALPA file access scanning work being done by Eric Paris
might be more appropriate.
See http://lwn.net/Articles/339399/
> Please CC: me on responses. I used to be subscribed, but the traffic was
> just too much.
You probably want the LSM mailing list (cc'd).
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: security module question
2009-08-05 2:02 ` James Morris
@ 2009-08-06 18:38 ` Eric Paris
2009-08-06 18:45 ` Shaya Potter
0 siblings, 1 reply; 4+ messages in thread
From: Eric Paris @ 2009-08-06 18:38 UTC (permalink / raw)
To: James Morris; +Cc: Justin Banks, linux-kernel, linux-security-module
On Wed, 2009-08-05 at 12:02 +1000, James Morris wrote:
> On Tue, 4 Aug 2009, Justin Banks wrote:
>
> > Hello - I'm trying to implement a security module that will allow or
> > disallow writes on files by byte ranges. Is there a way to use
> > inode_permission() to do this, or is there an alternative route I should
> > take? It doesn't look like inode_permission() will give me the data I
> > need (offset + length of write).
There is nothing that can do that. Neither fanotify nor the LSM.
Biggest problem is mmap.....
I think there was past kernel module which did this, but I don't
remember what they were called. Nothing which tracks this and could be
used was ever reasonable for the mainline kernel.
-Eric
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: security module question
2009-08-06 18:38 ` Eric Paris
@ 2009-08-06 18:45 ` Shaya Potter
0 siblings, 0 replies; 4+ messages in thread
From: Shaya Potter @ 2009-08-06 18:45 UTC (permalink / raw)
To: Eric Paris
Cc: James Morris, Justin Banks, linux-kernel, linux-security-module
Eric Paris wrote:
> On Wed, 2009-08-05 at 12:02 +1000, James Morris wrote:
>> On Tue, 4 Aug 2009, Justin Banks wrote:
>>
>>> Hello - I'm trying to implement a security module that will allow or
>>> disallow writes on files by byte ranges. Is there a way to use
>>> inode_permission() to do this, or is there an alternative route I should
>>> take? It doesn't look like inode_permission() will give me the data I
>>> need (offset + length of write).
>
> There is nothing that can do that. Neither fanotify nor the LSM.
> Biggest problem is mmap.....
>
> I think there was past kernel module which did this, but I don't
> remember what they were called. Nothing which tracks this and could be
> used was ever reasonable for the mainline kernel.
stackable file-system could do it (ala ecryptfs). You'd end up with
double page table usage (as they don't stack well), but you'd be able to
catch all mmap writes to disk.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-08-06 18:57 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-04 22:06 security module question Justin Banks
2009-08-05 2:02 ` James Morris
2009-08-06 18:38 ` Eric Paris
2009-08-06 18:45 ` Shaya Potter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.