All of lore.kernel.org
 help / color / mirror / Atom feed
From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Andrew Morgan <morgan@kernel.org>,
	Chris Wright <chrisw@sous-sol.org>,
	Andrew Morgan <agm@google.com>,
	casey@schaufler-ca.com, Andrew Morton <akpm@google.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	KaiGai Kohei <kaigai@kaigai.gr.jp>,
	James Morris <jmorris@namei.org>,
	linux-security-module@vger.kernel.org,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] file capabilities: introduce cap_setfcap
Date: Thu, 28 Jun 2007 10:33:18 +0900	[thread overview]
Message-ID: <46830FDE.7060502@ak.jp.nec.com> (raw)
In-Reply-To: <20070627171506.GA16764@sergelap.austin.ibm.com>

Serge E. Hallyn wrote:
> Here's the first patch (of several or many to come) to address some of
> Andrew's comments.
> 
> Kaigai, IIUC cap_names.h will eventually be automatically updated?  (I
> had to manually tweak it for testing as the new kernel sources were not
> located on the test system)

The origin of cap_names.h is "/usr/include/linux/capability.h".
Some scripts kicked by Makefile convert it, then cap_names.h will
be generated.

I don't know whether we can expect the kernel headers are always
deployed under "/usr/include/linux", or not.
In Fedora system, the kernel-headers package deploys all headers
there, so cap_names.h will eventually be automatically updated.

Thanks,

> thanks,
> -serge
> 
>>From fefcd341e478bd9e490d34abe9efd3c3c4f0b8a0 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <serue@us.ibm.com>
> Date: Wed, 27 Jun 2007 13:09:20 -0400
> Subject: [PATCH 1/1] file capabilities: introduce cap_setfcap
> 
> Setting file capabilities previously required the
> cap_sys_admin capability, since they are stored as
> extended attributes in the security.* namespace.
> 
> Introduce CAP_SETFCAP (to mirror CAP_SETPCAP), and
> require it for setting file capabilities instead of
> CAP_SYS_ADMIN.
> 
> Quoting Andrew Morgan,
> 
> "CAP_SYS_ADMIN is way too overloaded and this
> functionality is special."
> 
> Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
> ---
>  include/linux/capability.h |    4 +++-
>  security/commoncap.c       |   12 ++++++++++--
>  2 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index 89125df..cdfaa10 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -324,7 +324,9 @@ typedef __u32 kernel_cap_t;
>  
>  #define CAP_AUDIT_CONTROL    30
>  
> -#define CAP_NUMCAPS	     31
> +#define CAP_SETFCAP	     31
> +
> +#define CAP_NUMCAPS	     32
>  
>  #ifdef __KERNEL__
>  /* 
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 4e9ff02..24de4fa 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -290,7 +290,11 @@ int cap_bprm_secureexec (struct linux_binprm *bprm)
>  int cap_inode_setxattr(struct dentry *dentry, char *name, void *value,
>  		       size_t size, int flags)
>  {
> -	if (!strncmp(name, XATTR_SECURITY_PREFIX,
> +	if (!strcmp(name, XATTR_NAME_CAPS)) {
> +		if (!capable(CAP_SETFCAP))
> +			return -EPERM;
> +		return 0;
> +	} else if (!strncmp(name, XATTR_SECURITY_PREFIX,
>  		     sizeof(XATTR_SECURITY_PREFIX) - 1)  &&
>  	    !capable(CAP_SYS_ADMIN))
>  		return -EPERM;
> @@ -299,7 +303,11 @@ int cap_inode_setxattr(struct dentry *dentry, char *name, void *value,
>  
>  int cap_inode_removexattr(struct dentry *dentry, char *name)
>  {
> -	if (!strncmp(name, XATTR_SECURITY_PREFIX,
> +	if (!strcmp(name, XATTR_NAME_CAPS)) {
> +		if (!capable(CAP_SETFCAP))
> +			return -EPERM;
> +		return 0;
> +	} else if (!strncmp(name, XATTR_SECURITY_PREFIX,
>  		     sizeof(XATTR_SECURITY_PREFIX) - 1)  &&
>  	    !capable(CAP_SYS_ADMIN))
>  		return -EPERM;


-- 
Open Source Software Promotion Center, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

      reply	other threads:[~2007-06-28  1:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-27 17:15 [PATCH 1/1] file capabilities: introduce cap_setfcap Serge E. Hallyn
2007-06-28  1:33 ` KaiGai Kohei [this message]

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=46830FDE.7060502@ak.jp.nec.com \
    --to=kaigai@ak.jp.nec.com \
    --cc=agm@google.com \
    --cc=akpm@google.com \
    --cc=casey@schaufler-ca.com \
    --cc=chrisw@sous-sol.org \
    --cc=jmorris@namei.org \
    --cc=kaigai@kaigai.gr.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=sds@tycho.nsa.gov \
    --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.