This document is intended to specify the security goal that TOMOYO Linux is

trying to achieve, so that users can evaluate whether TOMOYO Linux will meet

their needs, and kernel developers can evaluate whether TOMOYO Linux deserved

to be in-tree.
1. About TOMOYO Linux
Project Homepage: http://tomoyo.sourceforge.jp/index.html.en

Project Wiki: http://elinux.org/TomoyoLinux
TOMOYO Linux is a DIY tool for understanding and protecting your system.

TOMOYO Linux policy definitions are absolutely readable to Linux users, and

TOMOYO Linux supports unique policy learning mechanism which automatically

gathers information and arranges the results as policy definitions.

These things made it possible for users to write policy from scratch.

Troubleshooting can be done by users.

We put some TOMOYO Linux policy examples on our web site.
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/etch/domain_policy.conf?...
2. TOMOYO Linux Security Goal
The TOMOYO Linux's security goal is to provide "MAC that covers practical

requirements for most users and keeps usable for most administrators".

TOMOYO Linux is not a tool for security professional but for average users

and administrators.
3. Our Approach
To meet the above goal, TOMOYO Linux attempts to make the system where

everything is prearranged in an easy-to-understand way.
  * Make the all subject's all access requests that will occur at least once

    during the lifetime of the kernel known in advance.
  * Let the administrator understand what access requests will each subject

    raise in his/her system and write policy which only allows expected and

    desirable access requests for his/her needs.
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from

attackers exploiting vulnerabilities in applications that the system hosts.

The threat is that an attacker can cause a vulnerable application to do

something unexpected and undesirable. TOMOYO Linux addresses this threat by

recording all applications' b...
[ message continues ]

This section seems to me to be the most important one, and could really
This email promised me a security goal, but instead of laying out

requirements it meets, its says it meets "practical requirements".

That's really not helpful.
What kernel resources does TOMOYO authorize?  All those which SELinux
So your point was that your main goal is simplicity?
Ok a few things you could add:
	1. Tomoyo provide no sort of information flow control.
	2. TOMOYO is purely restrictive.
	3. Learning mode is primary source of policy so you

	   depend on change of behavior to detect intruders.
	4. but any intruder who attempts to do something which

	   the compomised sftware wouldn't have done should be

	   stopped and detected.
This gives a precise (though perhaps wrong as I'm guessing :) picture

of what TOMOYO can do and how it fits in with SMACK, apparmor,

capabilities, and SELinux.
thanks,

--

Hello.
Thank you for feedback.
Yes, at least we believe so.
Have you ever heard an implementation that can automatically generate PIH

and restrict the behavior based on PIH?

Adding permissions to policy is not new because there is audit2allow

that can do it. But adding domains (or PIH) to policy is new.
Here's our version of Linux security comparison table.

TOMOYO can authorize part of kernel resources which SELinux can

and part of other resources which SELinux can't.
Currently, TOMOYO can authorize
  * execve() of programs.

  * open() of files for reading/writing.

  * creat()/link()/rename()/unlink()/symlink()/mkfifo()/mksock()/mkblock()/

    mkchar()/truncate()/mkdir()/rmdir() of files and directries

    that are visible to userland process's namespace.

  * namespace manipulation. (i.e. mount()/umount()/pivot_root())

  * TCP/IP networking operations based on IPv4/v6 addresses and port numbers.

    (Need to add LSM hooks for incoming connections/packets.)

  * booleans for some operations. (Part of POSIX capability and TOMOYO's

    original capability.)

  * signal transmissions. (Needs to add LSM hooks.)

  * argv[0] passed to execve().

Yes. Keep it understandable and customizable so that end users

Yes. TOMOYO is not intended to provide information flow control.

Controlling information flow is not the region of interest for TOMOYO.

(I'm not a security architect. I don't understand the definition and

coverage of "information flow" in security field.

I'm using "information flow" as "how information propagates".)
I think no access control can guarantee regarding information flow.

No access control can prevent attackers from leaking information

which are caused by means granted to attackers.

Even if some implementation can prevent attackers from leaking information

regarding an atomic operation, it does not guarantee that the implementation

can prevent attackers from leaking information as a whole system.

Attackers can still do nasty requests within given permissions.

...
[ message continues ]

Ok I didn't mean that as criticism, but a real question :)

Auto-learning in itself doesn't seem novel, but so you're saying it's
Does grsec's learning mode come closer to yours?  (I've never used
do you track mounts namespace cloning?
Well I don't see how you could without a new lsm hook  :)  But it seems

like something you'd need to really support this claim.  Any plans of
Right.
No need to defend it, not everyone needs it.  Just make it clear that

you don't care to support information flow control, then noone can

attack TOMOYO saying "it shouldn't be upstream bc it fails to provide
capability and multi-admin can provide extra privilege to non-root
Cool.
thanks,

-serge

--

Hello.
You can run your system with only policy collected by learning mode.

Thus, you basically don't need manual intervention.

But since there are randomly named files (i.e. temporary files),

you pay a little time to modify policy.
The learning mode is to save time for permitting commonly accessed resources.

Administrator reviews policy collected by learning mode. Thus the readability

of policy is important so that administrator can understand what he/she is

I looked at a glance. As far as I saw, it is not real-time policy generation.

It generates policy from logs like SELinux's audit2allow or AppArmor's

aa-genprof . Thus, I think grsec doesn't add domains in real-time like TOMOYO.

(I never used grsec too.)
It seems to me that grsec is designed for as fine grained access control

as SELinux's, while AppArmor and TOMOYO is designed for usability.

Yes. TOMOYO can recognize mount operation with the following flags.
  --bind --move --remount

  --make-unbindable --make-private --make-slave --make-shared
Although pathname based access control is not good at handling complicated

mount operations like http://lwn.net/Articles/159077/ , many systems don't

require such complicated ones.
Speak of bind mounts, there comes vfsmount problem.

AppArmor has been proposing patches to pass "struct vfsmount" parameter to

VFS helper functions and LSM hooks so that AppArmor/TOMOYO can determine

which pathname was requested in the bind-mounted environment.

Without the vfsmount patches, we can't calculate pathname without the risk of

AB-BA deadlock (if namespace_sem held) or crash (if namespace_sem not held).

I think we should start discussing how the vfsmount patches can be merged.

I'm sad to see no response for AppArmor's posting

I'm ready to submit patches for 2.6.24-rc6-mm1, but it seems to me that many

developers are offline. So, I'll submit patches when they come back to online.
Regards.

--

Please make a *big* notation someplace that "learning mode" is quite likely to

*not* produce a totally correct policy.  In particular, it won't build rules for

infrequently used code paths (such as error handling) unless you find a way to

exercise those paths while in learning mode.
Particularly fun - when learning mode doesn't create an entry for the logfile

for I/O errors.  Then when one actually happens, you have no idea what it was...

Hello.
Use of "learning mode" is independent from "correct policy".

The "learning mode" merely takes your duty of appending permissions to policy.

We can develop and share procedures for how to exercise infrequently used code

paths, like how to confirm that your SMTP service won't relay spams.

This problem is nothing but "developing and sharing procedures for how to

exercise infrequently used code paths" has not started yet.
By the way, what is the definition of "correct policy"?

The definition of "correct policy" depends on the user.
Some users may think that
  "A ready-made policy is better than a manually-made policy

   even if the ready-made policy contains unused/unneeded permissions.

   Being unable to handle infrequently used code paths is worse than

   leaving a room for not knowing/understanding what can happen."
but other users may think that
  "A manually-made policy is better than a ready-made policy

   even if the manually-made policy lacks permissions for infrequently

   used code paths.

   Leaving a room for not knowing/understanding what can happen is worse than

   being unable to handle infrequently used code paths."
You can use "permissive mode" to adjust and confirm your policy

before you use "enforcing mode".

You can also use "delayed enforcing mode" that allows an administrator

handle infrequently used code paths without once rejecting those code paths.

If the policy is not correct, it is the person's fault who enforced that policy

without confirming that that policy is suitable for his/her system.
Since the definition of "correct policy" is not a globally agreed word,

I think we can't say that "learning mode unlikely produces correct policy".
Thanks.

--

And I don't have an issue with the concept that you let a "learning mode"

develop 95% of the policy for you - as long as you make clear that you *do*

need to do some work to ensure all code paths are tested, or otherwise verify

that the generated policy is in fact correct.  For instance, semantic analysis

of the program source can identify what directories a program *should* create

files in - if some directories aren't in fact listed in the policy, they need

to be added.  If the actual learned policy includes directories that shouldn't

have been learned, you've got a *bigger* problem.  And yes, I have worked with

more than one case where a "benchline" measurement of a system happened to
Neither.
Policy *correctness* is a measure of how well the policy allows those

events that should properly happen, and rejects those events that should not

happen.  What you discuss here is what the relative impact of various *errors*

in the policy - basically, false-negative versus false-positive identification

of policy-violating activity.  Your first example says that it's preferable

to false-negative and fail to flag a violation, your second that it's

preferable to false-positive and flag something that should have been allowed.
In neither case are you actually talking about *correct* policy - which

would *properly* describe the desired behavior.  Note that how the policy

was *created* does not affect the *actual* correctness of the policy - it's

quite possible to create both correct and incorrect policies via both

manual and ready-made methods.
The *true* security question is:  What method minimizes your *total* cost of

both developing the policy and dealing with *both* the false positives and
I'm pretty sure that most of the security community agrees on what "correct"

means - the disagreement is in the most cost-effective way to *create* one.
Notice that I never said "learning mode is *unlikely* to produce correct policy".

What I said was "Learning mode *may* produce a correct polic...
[ message continues ]

Struth. (I'm practicing my Australian, it's gotten rusty)

I say that the the only rational way to create a policy is to

decide what you want the system to do and create your policy

based on that. I think that calling something that does nothing

more than enforce existing behavior without thought on what the

behavior ought to be a "policy" does disservice to the entire

security community. I realize that I'm in the minority on this

one. Oh well.
Casey Schaufler

casey@schaufler-ca.com

--

Yes... if you disallow access to /etc/nologin (or do something

similary stupid) you can even introduce security hole...

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

No, I mean clone(CLONE_NEWNS) and unshare(CLONE_NEWNS).  Without

tracking those, it seems like a convoluted sequence of mounting,

unmonting, and mount sharing and unsharing could potentially confuse

your policy or your admins...
I haven't fully thought it through.  But at least if an admin makes a

policy update with an expectation that all processes have the same mount
Don't require it, but that statement is only meaningful if you then
If the patches solve your problem, and you respond saying "TOMOYO needs
Sounds good.
thanks,

-serge

--

Hello.
TOMOYO doesn't expect that all processes have the same mount trees.

But TOMOYO expects that the mount trees won't change unless one of mount()/

umount()/pivot_root() are called.

Does a process get different mount trees by just calling clone() or unshare()?

My understanding is that clone() or unshare() disables propergation of

I'll say it when I submit patches.
Regards.

--

--

Hello.
Excuse me. To which statement did you say "yes"?
Does clone() or unshare() change visible directories without

calling following mount()/umount()/pivot_root()?
Regards.

--

--