linux-kernel - Re: [PATCH][RFC] Simple tamper-proof device filesystem.

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: <51953.81.207.0.53.1199738255.squirrel@secure.samage.net>
Date:	Mon, 7 Jan 2008 21:37:35 +0100 (CET)
From:	"Indan Zupancic" <indan@....nu>
To:	"Tetsuo Handa" <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	w@....eu, serue@...ibm.com
Subject: Re: [PATCH][RFC] Simple tamper-proof device filesystem.

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

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