[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.00.1007011057520.24202@tundra.namei.org>
Date: Thu, 1 Jul 2010 11:39:01 +1000 (EST)
From: James Morris <jmorris@...ei.org>
To: Christoph Hellwig <hch@...radead.org>
cc: Kees Cook <kees.cook@...onical.com>,
linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Yama: add PTRACE exception tracking
On Wed, 30 Jun 2010, Christoph Hellwig wrote:
> Err, no. This is just a very clear sign that your ptrace restrictions
> were completely wrong to start with and break applications left, right
> and center. Just get rid of it instead of letting workarounds for your
> bad design creep into the core kernel and applications.
Indeed, I wasn't aware that there were further aspects to this -- I
thought it was a relatively simple case of restricting a problematic OS
feature for heavily locked down systems.
This is getting more complicated, with fine-grained security policy now
being introduced, also with the need to modify applications.
There are several existing LSMs with the ability to control ptrace, but as
part of a system-wide, coherent, analyzable policy -- often in support of
specific security models for which there is concrete user demand and
benefit.
If people won't use any of SELinux, Smack, Tomoyo or AppArmor, then I
don't think providing an ad-hoc assortment of workarounds with no overall
design is going to help them either.
If LSMs need to call into common code in Yama, or even do lightweight
chaining, that's one thing, but for Yama to evolve into yet another
standalone security scheme, is something entirely different.
- James
--
James Morris
<jmorris@...ei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists