Re: [TOMOYO 14/15] Conditional permission support.
On Sep 19, 2007, at 08:15:53, Tetsuo Handa wrote: Kyle Moffett wrote: Look at it this way: What format do you use for your in-memory datastructures? If that format is not extremely close to the policy file format (with pointers replaced by 8-byte offsets), then you are using the wrong binary format. The more manipulations you have to do to a complicated data-structure the more likely you are to have a buffer-overflow or parsing bug. Before I answer, I would like to confirm one thing. Are you thinking that TOMOYO Linux kernel copies and keeps the contents of policy file represented in text format? Are you thinking that TOMOYO Linux kernel parses the contents of policy file represented in text format whenever permission checking occurs? If so, it's my lack of explanation. The text format representation of policy is used for communicating between kernel and userland. And this is the wrong user=kernel format, because this is not what the kernel directly uses. The binary format representation (e.g. adding length header for string data) of policy is used inside kernel space. This would be the right user=kernel format, (modulo using offset- from-start-of-policy instead of pointers). Then the validation part basically consists of walking the *same* data-structures that you are going to be using later, checking the length bytes, and converting all of the offset values into pointer values. Cheers, Kyle Moffett - 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 14/15] Conditional permission support.
Hello. Kyle Moffett wrote: This is probably not acceptable; I doubt there's a chance in hell that TOMOYO will get merged as long as it has text-based-language parsing in the kernel. You also have $NEW_RANDOM_ABUSE_OF_PROCFS and $PATH_BASED_LSM_ISSUES. See the long flamewars on AppArmor for discussion on the latter. Regarding /proc/tomoyo , this is not a big problem. It will be possible to create a dedicated filesystem after all other remaining problems are solved. Today, I found that I can use securityfs instead of procfs. Creating entry inside securityfs is more preferable way than developing a dedicated filesystem, am I right? 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 14/15] Conditional permission support.
On Tue, Sep 18, 2007 at 08:25:28PM +0900, Tetsuo Handa wrote: Hello. Kyle Moffett wrote: This is probably not acceptable; I doubt there's a chance in hell that TOMOYO will get merged as long as it has text-based-language parsing in the kernel. You also have $NEW_RANDOM_ABUSE_OF_PROCFS and $PATH_BASED_LSM_ISSUES. See the long flamewars on AppArmor for discussion on the latter. Regarding /proc/tomoyo , this is not a big problem. It will be possible to create a dedicated filesystem after all other remaining problems are solved. Today, I found that I can use securityfs instead of procfs. Creating entry inside securityfs is more preferable way than developing a dedicated filesystem, am I right? Yes, that it what it is there for. thanks, greg k-h - 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 14/15] Conditional permission support.
Hello. Kyle Moffett wrote: Yes, that's what securityfs is there for. Be mindful, though, that Thank you, I see. adding a text-based-language parser into securityfs is just as unacceptable as adding a text-based-language parser to procfs. Now, let me ask for some hints regarding text-based-language parsing in the kernel. It is true that TOMOYO Linux's policy is loaded into kernel in the text format. But the policy format is very simple. All policies are * sequentially parsable and processable (line-at-a-time, whitespace-delimited). * free of stack overflow (no recursive function calls). I can't imagine differences between text-based language parsing (i.e. policy file in text format) and binary-based language parsing (i.e. policy file in binary format). Even if I use policy file in binary format, I have to check whether the loaded policy is corrupted or not. TOMOYO Linux shares string data as const char * type to reduce memory used by security policy, and it speeds up string comparison by replacing strcmp() with pointer comparison. I can't use pointer to string data (in binary-based policy file) without verifying there are no duplicated string data in the kernel; otherwise, functions based on pointer comparison can't work properly. All other pointers have to be revalidated before I can use. It makes revalidation function very complicated and large. I think there exists, more or less, cost for policy validation in text-based and non-text-based policy. I doubt that (regarding TOMOYO Linux's policy file) making non-text-based language parsing worth the cost. TOMOYO Linux's policy is text-based, but is as simple as comma-separated-values (CSV) file. No difficulty or complexity is needed for validating policy. Pavel Machek wrote: What is that? Language parser in kernel? Yes, but is sequentially parsable text policy unacceptable? 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 14/15] Conditional permission support.
Hello. Kyle Moffett wrote: This is probably not acceptable; I doubt there's a chance in hell that TOMOYO will get merged as long as it has text-based-language parsing in the kernel. You also have $NEW_RANDOM_ABUSE_OF_PROCFS and $PATH_BASED_LSM_ISSUES. See the long flamewars on AppArmor for discussion on the latter. Thank you for your comment. Regarding /proc/tomoyo , this is not a big problem. It will be possible to create a dedicated filesystem after all other remaining problems are solved. Regarding text-based-language parsing in the kernel, it might be possible to use compiled policy. So, let me explain pitfalls of path based access controls and how TOMOYO Linux avoids these pitfalls. Since problems of pathname based access control is scattered around, I can't find all problems. But as far as I can see, it seems to me that they are confusing userland-specific problems and kernel-specific problems / white-listing approach and black-listing approach. Q1: Not all objects have pathnames! A1: What TOMOYO Linux does is use pathnames that are accessible via filesystem's mount tree. TOMOYO Linux does not deny labeling on objects that are not accessible via filesystem's mount tree. Although it is not implemented yet; it's a future work. I need to reduce my burden of catching up with the latest kernels. Q2: Pathname based access control is bypassed by creating hard links! Suppose an administrator wants to forbid access to /etc/shadow . Regarding pathname based access control, one can access to /etc/shadow by creating hardlinks to /tmp/shadow . Regarding label based access control, one can't access to /etc/shadow by creating hardlinks to /tmp/shadow because /tmp/shadow keeps the same label with /etc/shadow . A2: Do you think you need to allow creating hardlinks of /etc/shadow to /tmp/shadow ? I don't think so. Such operation is not needed for systems to operate properly. Thus, TOMOYO Linux forbids creating hardlinks of /etc/shadow to /tmp/shadow from the beginning. TOMOYO Linux handles pathnames carefully. TOMOYO Linux checks for both link-source and link-target together. One can't do ln /etc/shadow /tmp/shadow unless the administrator explicitly give allow_link /etc/shadow /tmp/shadow permission. The essential combinations of link-source and link-target are not infinite and TOMOYO Linux allows only essential combinations to minimize the risk of bypassing pathname based access control. Please remember, TOMOYO Linux is white-listing and system-wide access control. It's black-listing's approach that denies access to /etc/shadow but allows access to /tmp/shadow . White-listing approach will not allow access to /tmp/shadow unless explicitly given. TOMOYO Linux can apply access control including login session. One can't do ln /etc/shadow /tmp/shadow unless the administrator explicitly give allow_link /etc/shadow /tmp/shadow permission. Q3: Pathname based access control is bypassed by renaming files! Suppose an administrator wants to forbid access to /etc/shadow . Regarding pathname based access control, one can access to /etc/shadow by renaming to /tmp/shadow . Regarding label based access control, one can't access to /etc/shadow by renaming to /tmp/shadow because /tmp/shadow keeps the same label as /etc/shadow . A3: Do you think you need to allow renaming /etc/shadow to /tmp/shadow ? I don't think so. Such operation is not needed for systems to operate properly. Thus, TOMOYO Linux forbids renaming /etc/shadow to /tmp/shadow from the beginning. TOMOYO Linux checks for both old-name and new-name together. One can't do mv /etc/shadow /tmp/shadow unless the administrator explicitly give allow_rename /etc/shadow /tmp/shadow permission. The essential combinations of old-name and new-name are not infinite and TOMOYO Linux allows only essential combinations to minimize the risk of bypassing pathname based access control. You might worry that /etc/shadow can be renamed to /tmp/shadow between the moment the kernel got dentry and vfsmount from /etc/shadow and the moment TOMOYO Linux obtains a pathname from dentry and vfsmount. Yes, the possibility is not zero. But TOMOYO Linux is white-listing and system-wide access control. TOMOYO Linux allows only essential combinations of renaming requests. Thus, renaming /etc/shadow to /tmp/shadow will not happen unless the administrator explicitly give allow_rename /etc/shadow /tmp/shadow permission. Q4: Pathname based access control is bypassed by creating symbolic links! Suppose an administrator wants to forbid access to /etc/shadow . Regarding pathname based access control, one can access to /etc/shadow by creating symbolic links from /tmp/shadow to /etc/shadow . A4: This is because you are using pathnames before resolving symbolic
