All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Stephen Smalley <sds@tycho.nsa.gov>,
	lsm <linux-security-module@vger.kernel.org>,
	Chris Wright <chrisw@sous-sol.org>,
	James Morris <jmorris@namei.org>,
	Eric Paris <eparis@parisplace.org>,
	Casey Schaufler <casey@schaufler-ca.com>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH v2] security:  split proc ptrace checking into read vs. attach
Date: Thu, 15 May 2008 12:25:34 -0700 (PDT)	[thread overview]
Message-ID: <913573.56827.qm@web36607.mail.mud.yahoo.com> (raw)
In-Reply-To: <1210877785.28282.131.camel@moss-spartans.epoch.ncsc.mil>


--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> Enable security modules to distinguish reading of process state via
> proc from full ptrace access by renaming ptrace_may_attach to
> ptrace_may_access and adding a mode argument indicating whether only
> read access or full attach access is requested.  This allows security
> modules to permit access to reading process state without granting
> full ptrace access.  The base DAC/capability checking remains unchanged.
> 
> Read access to /proc/pid/mem continues to apply a full ptrace attach
> check since check_mem_permission() already requires the current task
> to already be ptracing the target.  The other ptrace checks within
> proc for elements like environ, maps, and fds are changed to pass the
> read mode instead of attach.
> 
> In the SELinux case, we model such reading of process state as a
> reading of a proc file labeled with the target process' label.  This
> enables SELinux policy to permit such reading of process state without
> permitting control or manipulation of the target process, as there are
> a number of cases where programs probe for such information via proc
> but do not need to be able to control the target (e.g. procps,
> lsof, PolicyKit, ConsoleKit).  At present we have to choose between
> allowing full ptrace in policy (more permissive than required/desired)
> or breaking functionality (or in some cases just silencing the denials
> via dontaudit rules but this can hide genuine attacks).
> 
> This version of the patch incorporates comments from Casey Schaufler
> (change/replace existing ptrace_may_attach interface, pass access
> mode), and Chris Wright (provide greater consistency in the checking).

Looks better to me.


Casey Schaufler
casey@schaufler-ca.com

  reply	other threads:[~2008-05-15 19:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-15 18:56 [RFC][PATCH v2] security: split proc ptrace checking into read vs. attach Stephen Smalley
2008-05-15 19:25 ` Casey Schaufler [this message]
2008-05-15 19:37 ` Serge E. Hallyn
2008-05-15 19:45   ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=913573.56827.qm@web36607.mail.mud.yahoo.com \
    --to=casey@schaufler-ca.com \
    --cc=chrisw@sous-sol.org \
    --cc=eparis@parisplace.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sds@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.