All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wright <chrisw@sous-sol.org>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	James Morris <jmorris@redhat.com>,
	Andrew Morgan <morgan@kernel.org>,
	Andreas Gruenbacher <agruen@suse.de>,
	Andrew Morton <akpm@osdl.org>, Chris Wright <chrisw@sous-sol.org>,
	Randy Dunlap <randy.dunlap@oracle.com>
Subject: Re: [PATCH 2/2] file capabilities: remove CONFIG_SECURITY_FILE_CAPABILITIES
Date: Wed, 24 Sep 2008 16:49:03 -0700	[thread overview]
Message-ID: <20080924234857.GA22375@sequoia.sous-sol.org> (raw)
In-Reply-To: <20080924020526.GA26058@us.ibm.com>

* Serge E. Hallyn (serue@us.ibm.com) wrote:
> Remove the option to compile the kernel without file capabilities.  Not
> compiling file capabilities actually makes the kernel less safe, as it
> includes the possibility for a task changing another task's capabilities.
> 
> Some are concerned that userspace tools (and user education) are not
> up to the task of properly configuring file capabilities on a system.
> For those cases, there is now the ability to boot with the no_file_caps
> boot option.  This will prevent file capabilities from being used in
> the capabilities recalculation at exec, but will not change the rest
> of the kernel behavior which used to be switchable using the
> CONFIG_SECURITY_FILE_CAPABILITIES option.

(note: defconfig has CONFIG_SECURITY_FILE_CAPABILITIES=y)
   text    data     bss     dec     hex filename
6805157 1018344  671900 8495401  81a129 obj64-defconfig/vmlinux
6805151 1018368  671900 8495419  81a13b obj64-defconfig-patch1/vmlinux
6805151 1018368  671900 8495419  81a13b obj64-defconfig-patch2/vmlinux
6804605 1018344  671900 8494849  819f01 obj64-nofcap/vmlinux
6804604 1018344  671900 8494848  819f00 obj64-nofcap-patch1/vmlinux
6805150 1018368  671900 8495418  81a13a obj64-nofcap-patch2/vmlinux

The last 2 show the real diff now, add 570 bytes by effectively forcing
CONFIG_SECURITY_FILE_CAPABILITIES on.

What is being done to enable userspace in distros to make those 570
bytes generally useful?

thanks,
-chris

  parent reply	other threads:[~2008-09-24 23:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-24  2:04 [PATCH 1/2] file capabilities: add no_file_caps switch (v3) Serge E. Hallyn
2008-09-24  2:05 ` [PATCH 2/2] file capabilities: remove CONFIG_SECURITY_FILE_CAPABILITIES Serge E. Hallyn
2008-09-24  4:59   ` Andrew G. Morgan
2008-09-24 23:49   ` Chris Wright [this message]
2008-09-25  1:02     ` Serge E. Hallyn
2008-09-25  1:19       ` Chris Wright
2008-09-25  1:36       ` Andreas Gruenbacher

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=20080924234857.GA22375@sequoia.sous-sol.org \
    --to=chrisw@sous-sol.org \
    --cc=agruen@suse.de \
    --cc=akpm@osdl.org \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=randy.dunlap@oracle.com \
    --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.