Re: TOMOYO Linux Security Goal
Quoting Tetsuo Handa ([EMAIL PROTECTED]): Hello. Serge E. Hallyn wrote: * namespace manipulation. (i.e. mount()/umount()/pivot_root()) do you track mounts namespace cloning? Yes. TOMOYO can recognize mount operation with the following flags. --bind --move --remount --make-unbindable --make-private --make-slave --make-shared 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... Oh, I see. TOMOYO doesn't track clone() and unshare(). 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 trees the result could be unsafe. 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 mount tree changes when somebody calls mount() or umount() or pivot_root(). Yes, with further propagation rules possible. 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 at http://lkml.org/lkml/2007/12/20/182 . If the patches solve your problem, and you respond saying TOMOYO needs these patches too, it just might get the thread going. I'll say it when I submit patches. Regards. - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TOMOYO Linux Security Goal
Quoting Tetsuo Handa ([EMAIL PROTECTED]): Hello. Serge E. Hallyn wrote: Does a process get different mount trees by just calling clone() or unshare()? My understanding is that clone() or unshare() disables propergation of mount tree changes when somebody calls mount() or umount() or pivot_root(). Yes, with further propagation rules possible. Excuse me. To which statement did you say yes? Sorry, yes your understanding was correct. Does clone() or unshare() change visible directories without calling following mount()/umount()/pivot_root()? Regards. - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TOMOYO Linux Security Goal
On Sun, 30 Dec 2007 14:29:50 +0900, Tetsuo Handa said: Use of learning mode is independent from correct policy. My point *exactly*. 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. 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 include an actual intrusion 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. 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 negatives of a possibly incorrect policy? 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. 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 policy, but there is a non-zero probability that needed things will remain unlearned unless care is taken to ensure they are learned. And I've been in this industry long enough to have *many* teeth marks where I've been bitten by very small but non-zero probabilities :) pgpPFvDpVlgqF.pgp Description: PGP signature
Re: TOMOYO Linux Security Goal
Hello. Serge E. Hallyn wrote: * namespace manipulation. (i.e. mount()/umount()/pivot_root()) do you track mounts namespace cloning? Yes. TOMOYO can recognize mount operation with the following flags. --bind --move --remount --make-unbindable --make-private --make-slave --make-shared 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... Oh, I see. TOMOYO doesn't track clone() and unshare(). 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 trees the result could be unsafe. 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 mount tree changes when somebody calls mount() or umount() or pivot_root(). 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 at http://lkml.org/lkml/2007/12/20/182 . If the patches solve your problem, and you respond saying TOMOYO needs these patches too, it just might get the thread going. I'll say it when I submit patches. Regards. - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TOMOYO Linux Security Goal
Quoting Tetsuo Handa ([EMAIL PROTECTED]): Hello. Thank you for feedback. Serge E. Hallyn wrote: 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 Are they in fact unique? Yes, at least we believe so. 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 novel in ust how integrated it is - no mnual intervention necessary? 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. Does grsec's learning mode come closer to yours? (I've never used grsec, just got the impression it did a lot of auto-learning stuff) Here's our version of Linux security comparison table. http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison hey that's a nice chart. I'd link it explicitly from the doc... What kernel resources does TOMOYO authorize? All those which SELinux does? 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()) 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 it? * 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(). * environment variables' names passed to execve(). Cool - by all means keep this list in your next version of this doc. So your point was that your main goal is simplicity? Yes. Keep it understandable and customizable so that end users (i.e. administrators) can configure policy for their systems. 1. Tomoyo provide no sort of information flow control. 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.) 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 information flow control. 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. I'd argue, but it's really not relevant right now :) 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. But without these permissions, the system can't work properly. So, the region of interest for TOMOYO is how to minimize means granted to each PIH, although not all permissions TOMOYO can authorize. 2. TOMOYO is purely restrictive. Excuse me. What models are there other than restrictive? capability and multi-admin can provide extra privilege to non-root users. I'm not sure whether what TOMOYO is doing are categorized to restrictive model. 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. Yes. TOMOYO's power comes from know all and understand what requests can happen within this system. Cool. thanks, -serge - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TOMOYO Linux Security Goal
Hello. Thank you for feedback. Serge E. Hallyn wrote: 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 Are they in fact unique? 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. http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison What kernel resources does TOMOYO authorize? All those which SELinux does? 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(). * environment variables' names passed to execve(). So your point was that your main goal is simplicity? Yes. Keep it understandable and customizable so that end users (i.e. administrators) can configure policy for their systems. 1. Tomoyo provide no sort of information flow control. 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. But without these permissions, the system can't work properly. So, the region of interest for TOMOYO is how to minimize means granted to each PIH, although not all permissions TOMOYO can authorize. 2. TOMOYO is purely restrictive. Excuse me. What models are there other than restrictive? I'm not sure whether what TOMOYO is doing are categorized to restrictive model. 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. Yes. TOMOYO's power comes from know all and understand what requests can happen within this system. Regards. - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TOMOYO Linux Security Goal
Quoting Tetsuo Handa ([EMAIL PROTECTED]): 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 Are they in fact unique? 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?v=policy-sample 2. TOMOYO Linux Security Goal This section seems to me to be the most important one, and could really use a little more detail. The TOMOYO Linux's security goal is to provide MAC that covers practical requirements 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 does? for most users and keeps usable for most administrators. TOMOYO Linux is not a tool for security professional but for average users and administrators. 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, -serge 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' behaviors in the test environment and forcing all applications behave within recorded behaviors in the production environment. TOMOYO Linux has a unique concept of process invocation history (in short, PIH). The PIH is a developmental lineage of a process. When a process executes a program, the process creates a copy with fork() and replace the copy with execve(). TOMOYO Linux appends the pathname of the executed program to the PIH of the replaced process, and associates process's PIH (stored in task_struct) with a domain. As a result, the context switching (a.k.a. domain transition) is unidirectional. This rule allows administrator distinguish and manage fine-grained context. Domain transition forms tree structure like a directory tree of filesystems. Each domain has different set of permissions that are essential for that domain. 4. Things you can do with TOMOYO Linux. Create policy from scratch. You want to use ready-made policy files supplied by somebody else because testing all paths needed for your usage sounds boring? OK, then you can choose other implementations that provide ready-made policy files, but you should check whether these files contain enough permissions for your usage or not. It is inevitable thing to test all paths needed for your usage if you want to use white listing access control. Also, ready-made policy files tend to contain redundant permissions for your usage which often leads to serious problem. TOMOYO Linux is a DIY tool for understanding and protecting your Linux box. TOMOYO Linux's learning mode will automatically generate policy files with necessary and sufficient permissions for you. Understand all possible requests. TOMOYO Linux reports what is happening within your Linux box. You can have the security of knowing that no unexpected requests
