linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Andy Lutomirski <luto@amacapital.net>,
	Serge Hallyn <serge.hallyn@ubuntu.com>,
	Kees Cook <keescook@chromium.org>,
	Christoph Lameter <cl@linux.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Richard Weinberger <richard.weinberger@gmail.com>,
	Austin S Hemmelgarn <ahferroin7@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks  security in systems  using  capabilities
Date: Wed, 11 Nov 2015 05:54:41 -0500	[thread overview]
Message-ID: <20151111105441.GA20241@thunk.org> (raw)
In-Reply-To: <20151111101433.GA16765@ikki.ethgen.ch>

On Wed, Nov 11, 2015 at 11:14:34AM +0100, Klaus Ethgen wrote:
> > If you are going to do that level of auditing, then
> > you can also check to make sure it's not trying to explicitly
> > manipulate the processes's capability mask to set the bit in the
> > ambient capability mask (which is just another malicious use of the
> > capability).
> 
> Well, you audit one version. What if the developer sees: "Oh, there is
> one new shiny thing in kernel, called ambient capabilities. Lets set
> them to all my capabilities. That looks great", after you audited the
> code..?

But the developer can also change what files they look at; in fact,
they are *more* likely to make that kind of changes during the normal
course of development; not deliberately or maliciously, but as part of
adding a new feature to their program.  If you don't have time to
audit to make sure they aren't using some new capability feature
(which you can do using the simple application of "grep"), you don't
have time to audit to make sure they haven't changed something which
will cause their use of CAP_DAC_OVERRIDE to be dangerous.

Which is why I maintain it is very wierd that you are paranoid about
the first concern, but are blithely unconcerned about the second,
which is more likely.  And it is *because* you are the one who have
this extremely strange and selective paranoia, and most other people
won't, it seems fair (to me) that you are the one that has to pay the
extra cost of working around the problem.  After all, if you're this
paranoid, you must building all of your binaries from scratch, too.

(Or else you have to trust lots of package maintainers or distro
release engineers.  I'll remind you that some of the more catastrophic
security problems have come from Debian maintainers, some of which
made patches in code they didn't completely understand, and which had
nothing to do with elevated privileges.)  So the cost of patching init
to set the securebit should be in the noise for you.

Cheers,

						- Ted

  reply	other threads:[~2015-11-11 10:54 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-02 18:06 Kernel 4.3 breaks security in systems using capabilities Klaus Ethgen
2015-11-02 18:38 ` Richard Weinberger
2015-11-02 18:50   ` Andy Lutomirski
2015-11-02 19:16     ` [KERNEL] " Klaus Ethgen
2015-11-02 19:45       ` Andy Lutomirski
2015-11-05 10:19         ` [KERNEL] " Klaus Ethgen
2015-11-05 16:15           ` Serge E. Hallyn
2015-11-05 17:17             ` [KERNEL] " Klaus Ethgen
2015-11-05 17:34               ` Serge E. Hallyn
2015-11-05 17:48                 ` [KERNEL] " Klaus Ethgen
2015-11-05 19:01                   ` Andy Lutomirski
2015-11-05 22:08                     ` Serge E. Hallyn
2015-11-06 13:58                       ` [KERNEL] " Klaus Ethgen
2015-11-06 15:53                         ` Theodore Ts'o
2015-11-06 17:15                           ` Andy Lutomirski
2015-11-06 17:51                           ` Casey Schaufler
2015-11-06 18:05                             ` Serge E. Hallyn
2015-11-06 17:56                           ` [KERNEL] " Klaus Ethgen
2015-11-06 18:18                             ` Serge E. Hallyn
2015-11-07 11:02                               ` [KERNEL] " Klaus Ethgen
2015-11-08 17:05                                 ` Serge E. Hallyn
2015-11-09 16:28                                 ` Austin S Hemmelgarn
2015-11-09 17:23                                   ` [KERNEL] " Klaus Ethgen
2015-11-09 19:02                                     ` Austin S Hemmelgarn
2015-11-09 21:29                                       ` [KERNEL] " Klaus Ethgen
2015-11-10  0:06                                         ` Andy Lutomirski
2015-11-10 11:55                                           ` [KERNEL] " Klaus Ethgen
2015-11-10 12:40                                             ` Theodore Ts'o
2015-11-10 13:19                                               ` [KERNEL] [PATCH] " Klaus Ethgen
2015-11-10 13:35                                                 ` Austin S Hemmelgarn
2015-11-10 17:58                                                   ` [KERNEL] " Klaus Ethgen
2015-11-10 20:39                                                     ` Austin S Hemmelgarn
2015-11-10 13:41                                                 ` Klaus Ethgen
2015-11-11  2:04                                                 ` Theodore Ts'o
2015-11-11 10:14                                                   ` [KERNEL] " Klaus Ethgen
2015-11-11 10:54                                                     ` Theodore Ts'o [this message]
2015-11-11 11:13                                                       ` [KERNEL] " Klaus Ethgen
2015-11-10 15:25                                               ` [KERNEL] Re: [KERNEL] Re: [KERNEL] " Christoph Lameter
2015-11-05 16:19           ` Andy Lutomirski
2015-11-05 17:22             ` [KERNEL] " Klaus Ethgen
2015-11-02 18:52   ` Linus Torvalds

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=20151111105441.GA20241@thunk.org \
    --to=tytso@mit.edu \
    --cc=ahferroin7@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=richard.weinberger@gmail.com \
    --cc=serge.hallyn@ubuntu.com \
    --cc=serge@hallyn.com \
    --cc=torvalds@linux-foundation.org \
    /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;
as well as URLs for NNTP newsgroup(s).