linux-kernel - Re: [patch 1/2] [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: <200712162103.IEC69233.FFOFOOtJMQHSLV@I-love.SAKURA.ne.jp>
Date:	Sun, 16 Dec 2007 21:03:27 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	david@...idnewall.com
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

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 
> problem you're fixing?  (I'm sure you tried to explain this in your 
> original post, but your reasons weren't clear to me.)

In 2003, I was trying to make / partition read-only to avoid tampering system files.
Use of policy based mandatory access control (such as SELinux) is
one of ways to avoid tampering, but management of policy was a daunting task.
So, I tried to store / partition in a read-only medium so that
the system is free from tampering system files.

When I attended at Security Stadium 2003 as a defense side,
I was using devfs for /dev directory. The files in /dev directory
were deleted by attckers and the administrator was unable to login.
So I developed this filesystem so that attackers who got root privilege
can't tamper files in /dev directory.
Not many systems mount / partition for read-only mode,
thus there may be few needs for read-only / partition.

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