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

[Tetsuo Handa]

( 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/