On Fri, 2013-01-11 at 00:14 +0900, Tetsuo Handa wrote: > The reason I think is that people turn off LSMs because they are using LSMs > without understanding "what the current configuration is" and/or "how to > change > configuration". People do not spend (or cannot afford spending) resources for > understanding LSM's configuration.
This is not the point I am arguing. This is not about LSMs, how hard they are to configure, or how to 'fix' them. It certainly isn't about how one LSM is better, easier, or superior to another. This is about getting more information in userspace when operations fail. I'll quote an off list e-mail I received: Friendlier/more complete error messages would eliminate an awful lot of digging around trying to figure *what* the problem is, preparatory to discerning *where* the problem is and *how* to fix it. There are so many things that might go into fixing problems in an LSM. That's what you are talking about, but it isn't relevant here. This is about knowing WHAT the problem is, maybe helping with where and how. And this isn't just about LSM. Heck, LSMs are just a small part of it. I want extended errno interface to talk about DAC, capabilities, ACLs, LSMs, everything! > > The audit log is complete crap from a usability PoV. If a web admin is > > TOMOYO's audit log is very useful. TOMOYO is a security tool but is also > useful > for education/training/debugging/development/profiling etc. The TOMOYO audit log is a very poor fit for this as well. I'm not trying to be rude, but there is no reasonable way for applications to use it, it is TOMOYO specific, and it doesn't cover non-LSM errors. I want applications like httpd to be able to put what went wrong in its log message. I want python to be able to get extended information and present that up the stack. Nothing we have today comes close. My proposal isn't perfect, it suffers from the same problems as errno (except even worse because it is harder to save and restore), but at least it will usually be helpful... -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/