Hello everybody;
On the 03.08.2010 18:50, Kees Cook wrote:
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:
Al gave you some very clear advice how a the sticky check should be
This is patently false. "Very clear advice" would have included actionable
instructions. He (and everyone else) has ignored my requests for
clarification[2]. 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.
You're overlooking step zero of Al's advice: First, *think* about the issue
in a deep fashion, rather than a knee-jerk patch to fix one instance of
the problem.
I think this is unfair. This solution has been used for 15 years in other
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 attacks
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.
Okay, thanks for this explanation of why people don't want Yama as an LSM.
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.
I would say it in a different way:
"Since Yama has as a security model a container that is field with
functionality of other security packages that have a security model but
are no LSMs, then instead of making a new LSM like Yama the LSM
architecture should be overworked to make the whole security packages
and implicitly their security models LSMs."
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
To be honest, I don't think this is a reason. The reason I see is that a
"large" LSM consisting of a thrown in bunch of ad-hoc rules
may rule the structure of the security model of LSMs.
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.
But it was discussed that it should become at least an LSM. And it was
found out that:
1. No new unproven protections have been invented.
2. The functionalities/features were taken out of other security
packages that are no LSMs but (seem to) have a security model.
3. The question was not answered if the functionalities/features could
be done by already existing LSMs (eg. SELinux).
only closes one set of symlink attacks without addressing the general issue of
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.
Well, here we disagree. DAC is flawed, this fixes a giant class of security
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 a
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.
I have regression tests for all the Yama features. I can prove if it's
working or not.
That's out of context. The context was if the whole conceptual model
with all of its features is working and not if every single feature of
Yama is working.
I've seen two so far. Both are addressed with a one line fix. And I would
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
this.
Quick question: Now is that "SELinux doesn't consider the added granularity
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...
I don't know the answer to this, but other people I've asked have said they
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
SECCOMP.
You were told to go back and form an actual *security model*. What's important
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).
Cross-uid symlink following and cross-permission hardlink creation are
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.
-Kees
Have fun
Christian Stroetmann
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
