On Mon, Aug 02, 2010 at 02:51:13PM -0400, Valdis.Kletnieks@xxxxxx wrote:
On Mon, 02 Aug 2010 09:59:36 PDT, Kees Cook said:I think this is unfair. This solution has been used for 15 years in other
You're overlooking step zero of Al's advice: First, *think* about the issueAl gave you some very clear advice how a the sticky check should beThis is patently false. "Very clear advice" would have included actionable
instructions. He (and everyone else) has ignored my requests for
clarification. If you see how the check should be implemented, please
send a patch demonstrating how. I would greatly prefer having these
protections in the VFS itself.
in a deep fashion, rather than a knee-jerk patch to fix one instance of
hardened kernel patches. It's not knee-jerk at all. Not fixing this is not
getting the "good" for the sake of wanting the "perfect".
The problem is that although your patch closes *one set* of symlink attacksOkay, thanks for this explanation of why people don't want Yama as an LSM.
that has been traditionally a problem, it doesn't do a very good job of
creating a conceptual model and then *really* dealing with the issue. That's
the big distinction between SELinux, Tomoyo, Smack, and your proposal - they
form a *model* of what's important to protect, and what actions need to be
taken to *actually* protect them. They don't just apply one arbitrary rule
that closes some attacks - they make an honest effort to deal with all
variants of the attack, and other attacks that allow bypass, and so on.
I disagree with the logic, but at least I understand the reasoning now.
"Since Yama does not provide a security model, it cannot be an LSM." This
then leaves a gap for people wanting to make small changes to the logic of
how the kernel works without resorting to endlessly carrying a patchset.
The reason people are worried that this might grow into a "large" LSM is that
quite often, throwing in a bunch of ad-hoc rules may create *apparent*
security, but not provide any *real* security. You yourself admit that Yama
I can accept this as a theoretical position, but it's not like I've
suddenly invented some new unproven protection. Given a choice between
fighting to have it be an LSM and fighting to have it in the VFS, I prefer
the VFS, since I'm trying to fix a flaw in DAC.
only closes one set of symlink attacks without addressing the general issue ofWell, here we disagree. DAC is flawed, this fixes a giant class of security
symlinks, hard links, TOCTOU races, and a lot of *other* similar "the file you
actually opened is not the one you intended to open" attacks. And the reason it
doesn't address the general issue is because it lacks a security model. And
the reason you're having so much trouble getting it into the tree is because if
you're going to apply this at either the VFS or LSM layers, you need to address
the *general* problem and not one ad-hoc variant of it.
problems. The model is "fix what sticky means for symlinks" and "fix when
hardlinks are created". :P
And quite frankly, the idea of this morphing into a "large" LSM containing aI have regression tests for all the Yama features. I can prove if it's
lot of ad-hoc rules scares most security people, because without a good
conceptual model, it's hard to define if the security is in fact working, or
what the problem is if it isn't working.
working or not.
I don't know the answer to this, but other people I've asked have said theyI've seen two so far. Both are addressed with a one line fix. And I wouldQuick question: Now is that "SELinux doesn't consider the added granularity
stress that no other existing subsystem in the kernel can provide the same
level of control that my ptrace exception logic provides. SELinux cannot do
important and doesn't bother doing it", or "SELinux can't do it *currently*",
or "there are innate structural reasons why SELinux is by design unable to do
it"? Note that it's a big difference, and it's dangerous for your cause to
bring it up without understanding which it is, and why...
didn't think it was possible. I would tend to agree since it requires an
explicit action from the debugee.
MAC is system-owner defined. This is programmer defined. I want my program
to be able to declare that a single specific pid can PTRACE it and nothing
else. Another example of programmer defined access control would be the
ability to "give up" access to syscalls, a finer-grained version of
You were told to go back and form an actual *security model*. What's importantCross-uid symlink following and cross-permission hardlink creation are
to protect? What attacks can be made against it? What syscalls are included in
the forseeable attacks (hint - probably more than you think - if you're
mediating symlink access, a bit of thought will show symlinks aren't the only
problem you need to worry about to *actually* secure the resource).
flaws in DAC that lead to a large persistent class of ToCToU
vulnerabilities that are trivially avoidable. It's been fixed for 15 years.
I'm not exactly sure how to model this. We've discussed how shared /tmp is
one aspect of the problem, but it's not the entire problem. We've discussed
how per-user /tmp is untenable in the short-term, etc. This is a way to get
there now while per-user /tmp is slowly adopted over the next 15 years.