On Mon, 2007-01-29 at 10:55 -0700, Eric W. Biederman wrote: > James Morris <[EMAIL PROTECTED]> writes: > > > On Mon, 29 Jan 2007, Stephen Smalley wrote: > > > >> NAK. Mapping all sysctls to a single security label prevents any kind > >> of fine-grained security on sysctls, and current policies already make > >> use of the current distinctions to limit access to particular sets of > >> sysctls to particular processes. As is, I'd expect breakage of current > >> systems running SELinux from this patch, because (confined) processes > >> that formerly only required access to specific sysctl labels will > >> suddenly run into denials on the generic fallback label. > > > > Agreed, 100% NACK. > > > > Please don't just simply remove long-researched & analyzed MAC security > > which has been in the kernel for years, which is being used in the field > > for high assurance systems, because you neglected to consider it during a > > code cleanup. > > Please don't shoot the messenger when a weakness is found in your code.
I'm not sure how breaking our code with your set of patches qualifies as finding a weakness. I will agree that the current handling of sysctl in selinux is fragile and can be improved, but it did work (prior to your patches). > Systems that increase security without worry that their implementation > is correct do not impress me, but I do understand that security has > little to do with correctness and everything to do with making it > _expensive_ for the other guy to do what he isn't supposed to. I think you misunderstand; we are concerned about the correctness of our implementation. I think that possibly you are misunderstanding one of the SELinux FAQ answers outside of its historical context (the initial release of a proof-of-concept implementation of flexible MAC in Dec 2000). > This code path was always in the selinux code for when /proc was > compiled out. I could see no way to preserve it so I removed > it. > > Not knowing if it was a problem, or if we needed to do something more > I copied the people who did, at the first available opportunity. > Before this code makes it's way into peoples production systems. Which we appreciate, although it would be nice if you tried building with selinux (and ideally testing with it) in the first place. > Of course after all of the rants against path based security I was > amazed to find a code path that was using exactly that in selinux. To clarify, in this case, the pathname (relative to the root of proc) is derived from the proc_dir_entry hierarchy and is thus not ambiguous or mutable by userspace, unlike the pathname-based approaches that we have criticized. There is a difference. But we are open to improving the approach via explicit marking of the ctl_table entries with sufficient information. > I'm trying to make things correct, and simple and will be happy to > work with you in a way to achieve what you need in a way that does > not conflict with the rest of the kernel. Good. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
