linux-kernel - Re: [RFC][PATCH] security: split ptrace checking in proc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1210762984.6206.293.camel@moss-spartans.epoch.ncsc.mil>
Date:	Wed, 14 May 2008 07:03:04 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Chris Wright <chrisw@...s-sol.org>
Cc:	casey@...aufler-ca.com,
	lsm <linux-security-module@...r.kernel.org>,
	James Morris <jmorris@...ei.org>,
	Eric Paris <eparis@...isplace.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] security:  split ptrace checking in proc


On Wed, 2008-05-14 at 02:15 -0700, Chris Wright wrote:
> * Stephen Smalley (sds@...ho.nsa.gov) wrote:
> > As above, it isn't quite a read vs. readwrite mode distinction (which is
> > why I called it ptrace_may_readstate rather than just ptrace_may_read),
> > and the advantage of implementing it via a new interface is that we only
> > need to update the callers where we want to apply this different
> > checking, leaving all other callers unmodified and unaffected.  So while
> > I could do it the way you describe, I'm not sure it would yield a better
> > result.  Maybe others can chime in with their opinions.
> 
> It is slightly ad-hoc.  Is it just the audit messages that you described
> that made you pick environ and fd, or was there more specific (threat
> based) reasoning?  Would /proc/pid/fd/ + genfs + e.g. anonfd be a little
> wider than just readstate?

Well, it is being driven by experience with what applications try to
access w/o requiring full ptrace access, but also by a threat-based
reasoning that it is less dangerous to grant limited read access to
parts of the process state than to grant complete read access to its
entire memory image or full control of the target process.

Not entirely sure what you mean by the latter question.

> Perhaps you could update the comments in ptrace_may_inspect() to clarify.

Ok, will do.

-- 
Stephen Smalley
National Security Agency

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