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: <200712172159.HGE65679.LQJOOFFFVMOHSt@I-love.SAKURA.ne.jp>
Date:	Mon, 17 Dec 2007 21:59:32 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	indan@....nu
Cc:	david@...idnewall.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

Hello.

Indan Zupancic wrote:
> If MAC can avoid all that, then why can't it also avoid tampering with /dev?

If MAC implementation handles filename and its attributes pair, this filesystem is not needed.
But I don't know MAC implementations that handle this pair.

SELinux's granularity is "allow foo_t to create block device file in dev_t directory".
TOMOYO's granularity is "allow foo to create block device file named /dev/sda1".
Both don't enforce filename and its attributes pair,
thus the attacker with root privilege can create fake device files
if he/she is permitted to create device files by MAC's policy.

It would be possible to handle this pair within MAC's policy
by expanding their policy syntaxes,
but offloading this handling on filesystem can make MAC's policy syntax simple
because filename and its attributes pairs are conventionally constant.
You won't let foo_t to create /dev/sda1 with block-8-1 attributes
and let bar_t to create /dev/sda1 with block-8-2 attributes, will you?
You don't want to describe attribute information to every entry in MAC's policy, do you?
It is redundant to describe this attribute enforcement information in MAC's policy
unless you want to break conventional filename and its attributes pairs.

> What security does your filesystem add at all, if it's useless without a MAC
> doing all the hard work?
Allow / partition to be mounted for read-only mode.
Allow /dev partition to be enforced filename and its attributes
to avoid /dev/null spoofing (create /dev/null as a regular file for eavesdropping purpose).

This filesystem adds filename and its attributes enforcement,
but it is overridable if this filesystem is used without MAC.
This filesystem adds unoverridable filename and its attributes enforcement
if this filesystem is used with MAC.

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