Message-ID: <78690.1280871500@localhost>
Date:	Tue, 03 Aug 2010 17:38:20 -0400
From:	Valdis.Kletnieks@...edu
To:	Kees Cook <kees.cook@...onical.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	James Morris <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, Al Viro <viro@....linux.org.uk>
Subject: Re: Preview of changes to the Security susbystem for 2.6.36

On Tue, 03 Aug 2010 09:50:10 PDT, Kees Cook said:

> > 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 fact that a patch for one case has been used for years doesn't mean
that it's a well thought out fix for the general case.

> 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.

It will likely not be accepted as an in-tree LSM, especially given that currently
it's rather difficult to stack two LSM's - which means that if a site wants to
run Yama, it becomes unable to take advantage of all the *other* security
features of SELinux or something similar.  In other words - if you want to be
an LSM, you need to be full-featured enough to cover all the bases, not just
a few cherry-picked ones.

You're of course free to keep a patchset that adds a private LSM, which should
be fairly immune to inter-release changes because the LSM hooks are pretty
set in stone and rarely change.

> 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

That's not a model.  A model is "these are the things that need to be
protected, these are the threats/attacks, and here are the ways we do to
protect".  I won't disagree with the concept that DAC isn't usually sufficient
- the point is that ad-hoc fixes for the low-hanging fruit isn't doing anybody
any favors.

> > 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.

The problem is that "proving it does what it claims" and "proving it
actually provides security" are two very different things.

If somebody attacks via a different symlink attack than Yama checks for, is it
a Yama failure? If somebody attacks via a non-symlink attack, was that a Yama
failure or no?

If I find a way to trick SELinux into allowing me to scribble on /etc/passwd,
that's an SELinux failure.  If I find a way to do an end-run around Tomoyo, or
Smack, or AppArmor, that's a failure. And if I write to the SELinux or Tomoyo
or Smack or AppArmor folks, I'm quite certain they'll all send back a reply "Oh
damn, that shouldn't happen, we'll think about a policy or code fix to prevent
that".

But scribbling on /etc/passwd by using any of the 4,394 different known attacks
against Linux except the 1 that Yama protects against isn't considered a
problem.

Do you see the difference?

"There are two kinds of cryptography in this world: cryptography that will stop
your kid sister from reading your files, and cryptography that will stop major
governments from reading your files.  This book is about the latter."
		-- Bruce Schneier, "Applied Cryptography"

The same sort of distinction applies to security.

> 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.

So let's see - the program needs some way to *find* said "single specific pid".
It checks the value of getppid()? Easily spoofable - I fork/exec it, wait for
it to say "parent can trace", then trace.  It checks in a file? If I can fake that
file out (with, perhaps, a symlink or race that Yama doesn't protect against),
I can do the ptrace.  Send it via a unix-domain socket or mmap or shmem?
See passing in a file. Or maybe I can force an OOM to kill the "real" pid,
then a quick fork() loop till I get that pid on the wrap-around. Or  maybe I'm
just a bastard and get control of the pid the program declares as "may ptrace'
and then do nothing at all just to DoS the process that you *wanted* tracing you.

I'm sure there's several dozen other practical attacks that a motivated
attacker can come up with. So now you've traded "protect one ptrace() syscall"
for "protect against abuse of at least a dozen system calls".

That's why you need an actual model, not ad-hoc rules.  Start with "This program
has data we don't want leaked, by ptrace or any other means".  Work from there.





Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists