>> 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
> environments :(((
> But I'm confident that with more optimization work TOMOYO will overcome this.
For true high-security environments, I don't expect pathname-based MAC
can be the first candidate (and SELinux is there). Hopefully, TOMOYO and
other pathname-based MAC will be able to work with label-based MAC in the future.
In any case, it is clear we need to improve the performance as much as possible.
> The backslashing of shell metacharacters and numbered rather than
> named 'profiles' remains horrid (but can be overcome with a preprocessing
I understand your points, but there's a compatibility issue, too.
Anyway thank you for your suggestions.
> 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.
I can't agree with you more. :-)
Those directory were named by the architect of TOMOYO Linux.
The project has had several meetings and the conclusion was respect his choice.
(I think he has the right to name it and if we force him to change, his
motivation has been changed also ;-)
>>> 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,
Well, IMHO, the fact that Linux has no limit does not mean you should do it. ;-)
In TOMOYO Linux, MAC can be controlled per domain basis.
(SELinux also has permissive domains)
So, if you want to give permission for certain domain to access 135 or
more deep, you just can put the mode in permissive or disable ( you don't have to
type /\*/\*/... Gee, it's really hard to type ;-)
If you do care the domain, I think it's worth to define /\*/*\... for 135 lines or more.
(This is just my opinion though)
> 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...
Actually, you were not the first person that suggested recursive thing.
One of the reason we didn't take that was the simplicity in the kernel.
I think I am going to talk project members again.