On Thu, 31 May 2001, Chris Wright wrote: > * Stephen Smalley (sdsat_private) wrote: > > > > > The dummy functions don't really provide much in the way of security. They > > > fall some where between DAC and everybody is root. Stephen Smalley has > > > suggested re-evaluating the dummy code and adding root checks to align with > > > DAC. I am inclined to fix this in dummy_setnice rather than > > > sys_setpriority. > > > > This doesn't fix the setpriority problem, as others have mentioned. > > However, it does need to be addressed in the dummy code. I also had to > > address this issue in the SELinux module code so that a LSM kernel with > > the SELinux module provides both the traditional root checks and the > > SELinux checks. See the root checks in the task_has_capability() function > > in the attached file. This function is called by each of the hooks that > > corresponds to a capability check (with a few exceptions due to confusion > > over whether the hook is supposed to be "authoritative" or "override"). > > Likewise, each of the dummy hooks that corresponds to a capability check > > should call a function to perform these root checks so that a kernel > > built without any security modules provides reasonable behavior. > > I've made the change already to the dummy_capable() hook to check super > user. I'll work on upgrading the rest of the capable derviative dummy hooks > to use this check. > > > Also, the dummy code either needs to implement traditional setuid/setgid > > program handling in the compute_creds hook (as in both the capabilities > > plug and the SELinux module), or we need to restore the base kernel > > compute_creds function with that processing (in which case it would > > call the hook, and the current hook calls would be restored to > > calling the base kernel function), as I've previously suggested. > > As the LSM patch currently exists, setuid/setgid program execution > > doesn't work when no modules are enabled. > > This is a known issue. I'm inclined to implement a dummy version only > because I don't have a good idea of how to make a meaningful separation in > compute_creds so that it can be left in the kernel. > > -chris > What's wrong with making capability_plug THE dummy module? It could be replaced upon module registration, and it would *install* the kernel into the same state as if the LSM patch was not applied. Then the problem would be in one code, and verification that "with dummy installed it's exactly the same as the WITHOUT LSM module" would be possible. The dummy thing is nice, but it's an extra "module" to worry about. Since capability_plug is meant to exactly reproduce the same condition as the module without LSM... would seem logical (to me.) As far as the logic of the hook is concerned, the way things are currently set up, I fear that I have to agree with Titus. The code in sys.c seems to be "sequential", checking that first (for the author's "unknown-to-me" reason), and we're adding a "change", not necessarily in the function, but in our interpretation of why it's there, in the &&. no_nice is checked again further on by the patch, and the only difference is HOW it fails (i.e. the return code) and if it continues the for()... We're mixing -EPERM and -EINVAL in the KERNEL, not in the module. If no_nice returns the right one, couldn't we break it out of the current checks? Feebly Yours' J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 : Thu May 31 2001 - 11:22:47 PDT