public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruen@suse.de>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: "Andrew G. Morgan" <morgan@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [patch] file capabilities: Add no_file_caps switch
Date: Wed, 27 Aug 2008 17:29:18 +0200	[thread overview]
Message-ID: <200808271729.18220.agruen@suse.de> (raw)
In-Reply-To: <20080827135206.GA12919@us.ibm.com>

On Wednesday, 27 August 2008 15:52:06 Serge E. Hallyn wrote:
> Quoting Andreas Gruenbacher (agruen@suse.de):
> > Hello,
> >
> > here is a patch allowing to disable file capabilities via a kernel
> > command line option (once compiled in with
> > CONFIG_SECURITY_FILE_CAPABILITIES).
> >
> > We would like to ship our next round of products with file capabilities
> > compiled in, yet we feel that too many system utilities are still file
> > capabilitiy unaware, and so we would like to turn them off by default
> > initially. File capabilities can be used to grant privileges to binaries
> > which otherwise look "harmless", which is a security risk until utilities
> > like rpm have learned how to install and verify capabilities, etc.
> >
> > Any objections?
>
> Hi Andreas,
>
> No objections in general - if it makes you more comfortable shipping
> kernels with CONFIG_SECURITY_FILE_CAPABILITIES=y then it's worthwhile.
> However, can you elaborate on your concerns?

We don't have the time left for developing the few missing pieces and properly 
integrating file capabilities into our products (use in various packages, 
support in rpm, system management, manuals, release notes), and so I would 
like to have a way to turn them off by default for now.

> In particular, if as you say above the concern is really just that a
> file might have capabilities accidentally (or maliciously) enabled, then
> we should be able to just check for file_caps_enabled() at
> get_file_caps(), refusing to fill in the file capabilities.

My main concern is accidental granting of capabilities because of admin 
unawareness / lack of tool support. This could be taken care of by not 
loading the capabilities from disk.

> The other changes which you are canceling out confuscate the code but
> actually make no difference.

Well, the other difference is that with CONFIG_SECURITY_FILE_CAPABILITIES=y 
you currently lose the ability to pass on capabilities to other processes. Do 
you have good arguments why this feature is unnecessary? I don' think that 
having this feature was a good idea in the first place, but taking it away 
now after several years may break current users which may not have gotten 
converted, yet.

Thanks,
Andreas

  reply	other threads:[~2008-08-27 15:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-26 18:57 [patch] file capabilities: Add no_file_caps switch Andreas Gruenbacher
2008-08-26 20:28 ` Ingo Molnar
2008-08-27 13:52 ` Serge E. Hallyn
2008-08-27 15:29   ` Andreas Gruenbacher [this message]
2008-08-27 16:04     ` Serge E. Hallyn
2008-08-27 16:13       ` David Howells
2008-08-27 16:32         ` Alan Cox
2008-08-27 17:00           ` David Howells
2008-08-27 16:57       ` Andreas Gruenbacher
2008-08-27 17:04         ` David Howells
2008-08-27 18:58         ` Serge E. Hallyn
2008-08-27 21:14           ` David Howells
2008-08-28  0:05             ` James Morris
2008-08-28  0:48               ` Serge E. Hallyn
2008-08-28  1:57                 ` James Morris
2008-08-28 15:35           ` Andrew G. Morgan
2008-08-28 17:09             ` Serge E. Hallyn
2008-08-28 16:27           ` 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=200808271729.18220.agruen@suse.de \
    --to=agruen@suse.de \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox