[patch 0/2] [RFC] Simple tamper-proof device filesystem.

Hello. I have proposed this filesystem a few years ago. Once again, I'm proposing this filesystem toward inclusion into mainline. I'll update for -mm tree if this filesystem is likely acceptable. Regards. (This is a resent message of [00/02] since it seems to be dropped.) - To unsubscribe from

[patch 1/2] [RFC] Simple tamper-proof device filesystem.

A brief description about SYAORAN: SYAORAN stands for Simple Yet All-important Object Realizing Abiding Nexus. SYAORAN is a filesystem for /dev with Mandatory Access Control. /dev needs to be writable, but this means that files on /dev might be tampered with. SYAORAN can restrict

[patch 2/2] [RFC] Simple tamper-proof device filesystem.

Signed-off-by: Tetsuo Handa [EMAIL PROTECTED] --- fs/Kconfig | 21 + fs/Makefile |1 + 2 files changed, 22 insertions(+) --- linux-2.6.24-rc5.orig/fs/Kconfig +++ linux-2.6.24-rc5/fs/Kconfig @@ -1555,6 +1555,27 @@ config UFS_DEBUG Y here. This will result in

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Tetsuo Handa wrote: /dev needs to be writable, but this means that files on /dev might be tampered with. I infer that you mean /dev needs to be writable by anyone, not by just its owner or owner and group (conventionally root/root.) This goes against conventional wisdom, which is that

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Hello. David Newall wrote: Tetsuo Handa wrote: /dev needs to be writable, but this means that files on /dev might be tampered with. I infer that you mean /dev needs to be writable by anyone, not by just its owner or owner and group (conventionally root/root.) This goes against

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Tetsuo Handa wrote: David Newall wrote: Tetsuo Handa wrote: /dev needs to be writable, but this means that files on /dev might be tampered with. I infer that you mean /dev needs to be writable by anyone, not by just its owner or owner and group (conventionally root/root.)

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Hello. I meant that /dev must be mounted for read-write mode Again, why? You can mount / partition for read-only mode if you wish to do so. But you cannot make /dev directory for read-only. You won't be able to login to the system because /sbin/mingetty fails to chown/chmod /dev/tty* if

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Tetsuo Handa wrote: I meant that /dev must be mounted for read-write mode Again, why? You won't be able to login to the system because /sbin/mingetty fails to chown/chmod /dev/tty* if /dev is mounted for read-only mode. Good point. So, if only root can modify files in /dev,

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

But use of this filesystem is still valid when this filesystem is used with policy based mandatory access control (such as SELinux, TOMOYO Linux) because this filesystem guarantees where policy based mandatory access control can't guarantee (i.e. filename and its attribute). Policy based

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Hi, On Sun, December 16, 2007 13:03, Tetsuo Handa wrote: Hello. David Newall wrote: You won't be able to login to the system because /sbin/mingetty fails to chown/chmod /dev/tty* if /dev is mounted for read-only mode. Good point. So, if only root can modify files in /dev, what's the

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

On Sun, Dec 16, 2007 at 05:52:08PM +0100, Indan Zupancic wrote: What prevents them from mounting tmpfs on top of /dev, bypassing your fs? Or binding /dev/null over nodes they want to get rid of... Also, if they have root there are plenty of ways to prevent an administrator from logging in,

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Hello. Indan Zupancic wrote: What prevents them from mounting tmpfs on top of /dev, bypassing your fs? Mandatory access control (MAC) prevents them from mounting tmpfs on top of /dev . MAC mediates namespace manipulation requests such as mount()/umount(). Also, if they have root there are

Re: [PATCH] dio: falling through to buffered I/O when invalidationof a page fails

At 04:15 07/12/15, Zach Brown wrote: If anyone has a testcase - I can take a look at the problem again. I can try and throw something together.. - z I did a test by using fsstress. I modified the dio write() of fsstress to check return value, and input following command; # fsstress -d

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Tetsuo Handa wrote: If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...] Bob can't do that. Only root can. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Hello. David Wagner wrote: If the attacker gets full administrator-level access on your machine, there are a gazillion ways the attacker can prevent other admins from logging on. This patch can't prevent that. It sounds like this patch is trying to solve a fundamentally unsolveable problem.