On Sun, Apr 13, 2008 at 06:41:19PM -0700, Crispin Cowan wrote: > You are discussing a straw-man, because AppArmor (and I think TOMOYO) do > not operate that way. Thanks for clarifying that. I had to put a straw-man up for discussion because nobody else had. I'll continue this discussion in terms of allow-rules. > Rather, it is "can write to /tmp/ntpd/*". You *grant* permissions. You > do *not* throw deny rules. So primarily we're concerned here with things that are running as root, daemons and the like. Normal unix file permissions (or ACLs, if you must) are adequate to handle anything not running as uid 0. I don't see what apparmour and tomoya buy us that namespaces can't. Maybe a nicer interface, but that's something that a nice userspace management interface can handle. Create an empty namespace. Create /tmp/ntpd in it. Bind the outside /tmp/ntpd onto that directory. Presto, the equivalent to an allow-rule of 'can write to /tmp/ntpd/*'. The equivalent of 'can read, but not write /home/crispin/.ssh/id_rsa.pub' will need r-o bind mounts, which Miklos seems to have become distracted from by working on the hooks for TOMOYA. Do you have a good example of something that apparmour can protect against that namespaces can't? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
