All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: dhowells@redhat.com, "Andrew G. Morgan" <morgan@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Security Modules List 
	<linux-security-module@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/4] security: filesystem capabilities bugfix2
Date: Mon, 30 Jun 2008 20:10:41 +0100	[thread overview]
Message-ID: <14854.1214853041@redhat.com> (raw)
In-Reply-To: <20080630185318.GB30669@us.ibm.com>

Serge E. Hallyn <serue@us.ibm.com> wrote:

> > With Andrew's patch, capabilities are downgraded regardless of whether we
> > have CAP_SETPCAP or not.  I guess that means that if you're tracing a
> > binary whose filecaps say that it wants CAP_SETPCAP, then it retains
> > CAP_SETPCAP.
> 
> I don't understand where that last sentence comes from.  Why would it
> retain CAP_SETPCAP?

It seems I missed a bit out.  It should've read:

	I guess that means that if you're tracing a binary that has
	CAP_SETPCAP already, and whose filecaps say that it wants CAP_SETPCAP,
	then it retains CAP_SETPCAP.

If the debugger has CAP_SYS_PTRACE, then it can attach to a binary that has
CAP_SETPCAP according to cap_ptrace(), even if the debugger doesn't.

> > I wonder if the tracing task should be examined here, and any capability the
> > tracer isn't permitted should be denied the process doing the exec.
> 
> That sounds reasonable on its own, but it opens up a dangerous ability
> for the partially-privileged tracer to manipulate the capability set for
> the traced task.

Does it, though?  It would only reduce the capabilities of the inferior
process; it wouldn't allow the inferior process or the debugger to get
additional capabilities, apart from what's available under CAP_SETPCAP.

David

  reply	other threads:[~2008-06-30 19:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-26  8:48 [PATCH 2/4] security: filesystem capabilities bugfix2 Andrew G. Morgan
2008-06-27 20:59 ` Serge E. Hallyn
2008-06-30 14:53   ` David Howells
2008-06-30 18:53     ` Serge E. Hallyn
2008-06-30 19:10       ` David Howells [this message]
2008-06-30 19:49         ` Serge E. Hallyn
2008-06-27 23:04 ` David Howells
2008-06-30  5:41   ` Andrew G. Morgan
2008-06-30  9:45     ` David Howells

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=14854.1214853041@redhat.com \
    --to=dhowells@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=serue@us.ibm.com \
    /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.