On Sun, 8 Jul 2001, LA Walsh wrote: > For any any other place, security is in place to control access > between users. Any call of this nature needs a pre-hook for POSIX 1e > style MAC. MAC can be very restrictive. All of it's checks must > be done before you even get to the mode bits on a file because > data in the inode is part of what MAC protects. Same with > inter-process communication, sending signals, looking at another > process in /proc, etc. Ok, so we can address this problem by placing the restrictive hook call prior to the existing Unix access control logic in each case, if any Unix access control logic exists at that point. No objection here. This is already the case for some of the hooks, and the others shouldn't be hard to relocate. > It has been stated before: we don't want to call 'capable' > if the file mode is 0777. In the same way you don't want to return > a DAC failure when the user doesn't have "access" to the data in the > inode needed to perform a DAC check, instead they should get a MAC failure. > Of course, if they have appropriate privilege (appropriate Capability) > then they can override MAC policy and then do the DAC checks, which, > of course, can also be overridden with appropriate privilege. As I've previously pointed out, the existing short-circuit logic should handle this properly, ensuring that capable is only called if the DAC logic fails. For your MAC checks, this can be addressed by always placing the restrictive hook before the existing Unix access control logic. > All of the above can't be done if 'standard linux security' is > left 'immutable' in the kernel. You haven't made this case. See the above. > In the case of audit, it wants to know the values of parsed > arguments and security relevant information. This requires, > say, in "open", to record not only DAC pass/fail, but also > recording the file descriptor of a succcessful call. File > descriptors are the user space 'handle' the kernel provides to > the internal file struct. You can easily capture the file descriptor/return status via system call interposition. You don't need new kernel security hooks for this purpose. You can also generate quite a bit of useful audit data with just the access control hooks. SELinux supports fine-grained configurable auditing of access grantings and access denials, and I think most access control systems provide some kind of logging/auditing. The existing LSM hooks already provide you with appropriate access to kernel data structures after user space handles have been looked up. > So if we are going for stage I. We'd propose: > > 1) That the project adopt new prototypes for some of the existing > security calls to support the argument collection requirements of a > future audit implementation. Reason: We don't want to force an API change > once the it has been accepted into the kernel. This is fine with me if you are merely adding parameters (as opposed to replacing 'struct file' with 'fd' as in your original patch), the parameters are easily accessible at the point of the hook calls (which is a problem for some cases where you wanted the 'fd'), and the parameters provide additional information that is not already accessible (as opposed to passing the pid to ptrace as well as the task_struct). > 2) move to authoritative hooks with the standard security moved > into a module that is compiled in and completely compatible with > the current security (bug for bug, feature for feature). I know > this topic was discussed last month, but we couldn't give input > at that time. Not without prior buy-in by the kernel developers. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Jul 09 2001 - 08:22:32 PDT