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: <200712172232.CFI17125.tFHOFFQLSOOVJM@I-love.SAKURA.ne.jp>
Date:	Mon, 17 Dec 2007 22:32:06 +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.

( This is a reply to http://lkml.org/lkml/2007/12/17/27 .)

Hello.

David Wagner wrote:
> But the point is that it's not enough just to prevent attackers
> from mounting other filesystems over this filesystem.  I can think
> of all sorts of ways that an admin-level attacker might be able to
> prevent other administrators from logging in.  If your defense strategy
> involves trying to enumerate all of those possible ways and then shut
> them down one by one, you're relying upon a defense strategy known as
> "blacklisting".  Blacklisting has a terrible track record in the
> security field, because it's too easy to overlook one pathway.
Of course, I assume whitelisting.
SELinux and TOMOYO Linux and many other MAC implementations uses
whitelisting approach, and this filesystem is whiltelisting approach.

This filesystem handles what MAC implementations don't handle.
In other words, it is a remaining hole.

I'm proposing:

 Don't you think it is dangerous to assume files in /dev directory
 have appropriate filename and attributes binding?
 MAC can restrict processes who can create files in /dev directory,
 but MAC doesn't enforce filename and attributes binding.
 So, how about enforcing filename and attributes binding in filesystem layer?

Regards.

To David Wagner:
  Could you please Cc: me so that I can reply to your message?
  I can't reply to your message since I'm reading this ml in daily digest mode.
--
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/