On Tue, Jun 9, 2015 at 5:00 PM, Andy Lutomirski [off-list ref] wrote:
On Tue, Jun 9, 2015 at 4:09 PM, Kees Cook [off-list ref] wrote:
quoted
On Wed, May 27, 2015 at 4:47 PM, Andy Lutomirski [off-list ref] wrote:
quoted
[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.
quoted
quoted
[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.
quoted
quoted
[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 <redacted>
I would love to use this already. :)
-Kees
--
Kees Cook
Chrome OS Security