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
next prev 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.