Hello, Some questions: On Sun, January 6, 2008 16:20, Tetsuo Handa wrote:1) If the behaviour can be controlled, why can't the process be disallowed to change anything badly in /dev? Like disallowing anything from modifying existing nodes that weren't created by that process. That would have practically the same effect as your filesystem, won't it? Or phrased differently, if the MAC system used can't protect /dev, it won't be able to protect other directories either, and if it can't protect e.g. my homedir, doesn't it make the whole MAC system ineffective? And if the MAC system used is ineffective, your filesystem is useless and you've bigger problems to fix. 2) The MAC system may not be able to guarantee certain combinations of device names and properties, but isn't that policy that shouldn't be in the kernel anyway? But if it is, shouldn't all device nodes be checked? That is, shouldn't it be a global check instead of a filesystem specific one? 3) Code efficiency. Thousand lines of code just to close one very specific attack, which can be done in lots of different other ways that all need to be prevented by the MAC system. (mounting over it, intercepting open calls, duping the fd, etc.) Is it worth it? I really don't care how you try to protect your system, but I don't think this is an effective way to do it. Good luck, Indan --
| Andy Whitcroft | clam |
| Jon Smirl | Re: 463 kernel developers missing! |
| Trent Piepho | [PATCH] [POWERPC] Improve (in|out)_beXX() asm code |
| Linus Torvalds | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
git: | |
| Jarek Poplawski | Re: HTB accuracy for high speed |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Natalie Protasevich | [BUG] New Kernel Bugs |
