On Tue, Jun 9, 2015 at 5:00 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Tue, Jun 9, 2015 at 4:09 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> On Wed, May 27, 2015 at 4:47 PM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: >>> [1] Files that are missing the "security.capability" xattr or that >>> have unrecognized values for that xattr end up with has_cap set to >>> false. The code that does that appears to be complicated for no >>> good reason. >> >> Would it make more sense to have has_cap true, but have it lack any actual caps? > > I assume you're referring to the case where we fail to parse the > xattr. If so, I don't really know if or when this happens. Should > that be addressed separately from this patch set? No, no. All of these footnotes seem to be separate from the series. I just wanted to chime in on them, since none of them really sounded like they should get dropped. >>> [2] The libcap capability mask parsers and formatters are >>> dangerously misleading and the documentation is flat-out wrong. fE >>> is *not* a mask; it's a single bit. This has probably confused >>> every single person who has tried to use file capabilities. >> >> Sounds like it would be a valuable documentation patch. > > I'll try. Let's get the current thing done first. Yup! No worries. I'm happy to help with the docs, too. >>> [3] Linux very confusingly processes both the script and the >>> interpreter if applicable, for reasons that elude me. The results >>> from thinking about a script's file capabilities and/or setuid bits >>> are mostly discarded. >> >> I wonder if this is important enough to fix? > > Not sure. > > However, the fact that AFAICT LSM due to a script (as opposed to an > interpreter) is preserved sounds rather dangerous to me. I'm not sure > whether we can safely fix that at this point. Agreed. I missed adding: Acked-by: Kees Cook <keescook@xxxxxxxxxxxx> I would love to use this already. :) -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
