User: Password:
|
|
Subscribe / Log in / New account

2.6.30 merge window, part I

2.6.30 merge window, part I

Posted Apr 7, 2009 9:13 UTC (Tue) by haradats (guest, #44782)
In reply to: 2.6.30 merge window, part I by nix
Parent article: 2.6.30 merge window, part I

> I've had a look at it, and, well, the core idea (process execution
> history) is lovely, though the cost is high (a near-100% slowdown of
> open() for instance),

Did you see the following?
http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#benchmark
Yes, the cost for "open" is the worst, but others are not so bad
(read/write are not affected at all).

> but the configuration file syntax and user
> interface, ewwww. It renders it almost unusable in my eyes. You have
> *numbered* 'profiles' corresponding to (non-POSIX) capability sets, so you
> have to remember what each number corresponds to; backslashing of *all*
> metacharacters, including *, combined with the absence of an 'all below'
> option, leading to insanity like

I'm sorry for your eyes. ;-)

Profiles can be defined up to 256, but most cases you can live with
the following predefined ones.

profile 0: "disabled"
profile 1: "learning"
profile 2: "permissive"
profile 3: "enforcing"

Profile numbers have nothing with capabilities (and the just
merged version of TOMOYO Linux cannot control capabilities).
For more information, please take a look at the following documents.

http://tomoyo.sourceforge.jp/en/2.2.x/

> 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.

Questions and suggestions are always welcome. Please visit our forum, too.
http://sourceforge.jp/forum/forum.php?forum_id=11352&...

Thanks


(Log in to post comments)

2.6.30 merge window, part I

Posted Apr 7, 2009 19:44 UTC (Tue) by nix (subscriber, #2304) [Link]

> 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.

The backslashing of shell metacharacters and numbered rather than
named 'profiles' remains horrid (but can be overcome with a preprocessing
layer).

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,
nothing.

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...

2.6.30 merge window, part I

Posted Apr 10, 2009 13:38 UTC (Fri) by haradats (guest, #44782) [Link]

>> 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
> layer).

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,
> nothing.

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.

Thank you. /\*/\*/\*/

2.6.30 merge window, part I

Posted Apr 17, 2009 20:21 UTC (Fri) by nix (subscriber, #2304) [Link]

As far as I can see, you don't need recursion to do the 'any directory
below' thing at all.

(And, er, you can fix the syntax by allowing two syntaxes, although that
probably isn't a job for the kernel.)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds