lkml.org 
[lkml]   [2008]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH][RFC] Simple tamper-proof device filesystem.
From
Hello,

Some questions:

On Sun, January 6, 2008 16:20, Tetsuo Handa wrote:
> I want to use this filesystem in case where a process with root privilege was
> hijacked but the behavior of the hijacked process is still restricted by MAC.

1) If the behaviour can be controlled, why can't the process be
disallowed to change anything badly in /dev? Like disallowing anything
from modifying existing nodes that weren't created by that process.
That would have practically the same effect as your filesystem,
won't it?

Or phrased differently, if the MAC system used can't protect /dev, it
won't be able to protect other directories either, and if it can't
protect e.g. my homedir, doesn't it make the whole MAC system
ineffective? And if the MAC system used is ineffective, your
filesystem is useless and you've bigger problems to fix.

2) The MAC system may not be able to guarantee certain combinations
of device names and properties, but isn't that policy that shouldn't
be in the kernel anyway? But if it is, shouldn't all device nodes be
checked? That is, shouldn't it be a global check instead of a filesystem
specific one?

3) Code efficiency. Thousand lines of code just to close one very specific
attack, which can be done in lots of different other ways that all need
to be prevented by the MAC system. (mounting over it, intercepting open
calls, duping the fd, etc.) Is it worth it?

I really don't care how you try to protect your system, but I don't think
this is an effective way to do it.

Good luck,

Indan




\
 
 \ /
  Last update: 2008-01-07 21:41    [W:0.097 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site