> Yes, the cost for "open" is the worst, but others are not so bad
> (read/write are not affected at all).
Indeed, that's nice... but IIRC the cost for, say, SELinux for open() is
much lower. And open() is a *common* syscall, optimized to hell and back.
IMNSHO this restricts TOMOYO to high-security or low-performance
But I'm confident that with more optimization work TOMOYO will overcome
The backslashing of shell metacharacters and numbered rather than
named 'profiles' remains horrid (but can be overcome with a preprocessing
The consistent 'ccs' in the names of commands and /proc entries still has
no connection whatsoever that I can see to 'TOMOYO': why not rename or at
least provide links to more memorably-named commands?
I was under the impression that putting things like the TOMOYO ccs/
directories in /proc (or anything new at all not tightly related to
specific processes) was pretty seriously deprecated.
>> and hope your users don't create directories more than five deep under
>> their $HOME, and that you didn't make a typo in that appalling forest.
> Don't worry. You can define deeper directory patterns as you like.
But you can't say 'any depth', and without that you're just asking for
confusing failures. You can't sensibly assume any fixed depth for your
users' directory trees (one user of mine has directories *135* levels deep
for reasons known only to him and his god: do you want to make a policy
that caters for *that* with explicit .../\*/\*/...? No, neither do I.) And
Linux has *no* limit whatsoever on directory nesting depth, not PATH_MAX,
So you need a 'recursive' thing (like AppArmor has).
AppArmor is much less flexible than TOMOYO, and lacks the lovely
process-execution-history idea, but boyoboy are its config files more
readable. It pretty much did everything right from a user-interface design
perspective. You could profitably copy syntax from it...