From: ebiederm@xmission.com (Eric W. Biederman)
To: Tom Gundersen <teg@jklm.no>
Cc: Jiri Kosina <jkosina@suse.cz>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Andy Lutomirski <luto@amacapital.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Arnd Bergmann <arnd@arndb.de>,
        One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Daniel Mack <daniel@zonque.org>,
        David Herrmann <dh.herrmann@gmail.com>,
        Djalal Harouni <tixxdz@opendz.org>
References: <8738434yjk.fsf@x220.int.ebiederm.org>
	<20150413194217.GA10837@kroah.com>
	<20150413202233.GR889@ZenIV.linux.org.uk>
	<CALCETrUEAxFqwU4beeXYpdyRAO6yDRSNvcBqhvpMVORy00ySgg@mail.gmail.com>
	<CAFLxGvz9sn7rk1zU5tA8wPtn0T6ujR_tmEhLQeBcVOtKL00wdA@mail.gmail.com>
	<20150415084812.GG16381@kroah.com>
	<20150415122555.74258d63@lxorguk.ukuu.org.uk>
	<20150415154551.GE6801@home.goodmis.org>
	<20150415163520.GA25105@kroah.com>
	<20150415130649.6f9ab20f@gandalf.local.home>
	<20150415173145.GA26146@kroah.com>
	<20150415225611.0c256ea6@lxorguk.ukuu.org.uk>
	<CALCETrWBvT7Vhwir+ntk7A31Ux2C_3CeuWFk7iQqA1fovh74yg@mail.gmail.com>
	<552F8F97.3040208@zonque.org>
	<CAG-2HqXrc+oBpq2GFWwFs-3CjnUW0NKetwttQ+5HkxBRCPMqfw@mail.gmail.com>
Date: Tue, 21 Apr 2015 11:36:54 -0500
In-Reply-To: <CAG-2HqXrc+oBpq2GFWwFs-3CjnUW0NKetwttQ+5HkxBRCPMqfw@mail.gmail.com>
	(Tom Gundersen's message of "Thu, 16 Apr 2015 14:02:14 +0200")
Message-ID: <87mw21qvyx.fsf@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [GIT PULL] kdbus for 4.1-rc1
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3099
Lines: 68

Tom Gundersen <teg@jklm.no> writes:

> Moreover, the daemon performing the shutdown tasks is necessarily
> always privileged enough to do so, so calling into the kernel and see
> what happens is completely the wrong thing to do (it would simply
> succeed). What matters is if the client calling the daemon is
> sufficiently privileged. If the client has the capabilites necessary
> to call the reboot syscall directly, it makes no sense to disallow
> them from doing a clean reboot. It would be like giving someone access
> to pull the power plug, but not allow them to shutdown the machine
> cleanly.
>
> To conclude, the kernel makes the decision for allowing reboot() to
> succeed based on CAP_SYS_BOOT, so when we decide whether or not to
> perform the preparation steps, we really must also use CAP_SYS_BOOT.
> If we are more restrictive, it does not gain us anything as people
> with CAP_SYS_BOOT can just circumvent our logic and "pull the plug" by
> calling reboot() directly. If we are less restrictive and for instance
> check for uid==0 it would essentially mean that we have added a way to
> circumvent the dropping of CAP_SYS_BOOT.

*Blink*  Privilege escalation via CAP_SYS_BOOT *Blink*

*Puts on black hat*

HeHeHe.  You mean all I need to do to get around all of the logging servers is
capture CAP_SYS_BOOT?  Say like just capture this crazy watchdog program
that doesn't run as root so that it can only reboot the system? HeHeHe
So I can just trigger a clean reboot wait for journald, auditd, and
syslog all to shut down and then do evil things to the machine without
having to worry about erasing forensic evidence?

Bahahaha! This looks like fun I should play with this.

*Takes black hat off* 

Seriously it does not make sense to reuse these bits for purpose to
which they were not designed.   A reboot proceeded by a clean shutdown
is something different from a reboot that skips all of those steps.

I can understand the concerns about not wanting to allow circumventing
dropping CAP_SYS_BOOT but even with that concern in place I think it is
silly.  That isn't what CAP_SYS_BOOT means.

Over the long term userspace doing weird things like this will mean that
we will have the change the kernel to add
CAP_SYS_BOOT_THIS_TIME_I_MEAN_IT.  And have that control the reboot
system call and have the existing CAP_SYS_BOOT be some kind of token for
userspace.

Instead of going down that rat hole it would be much better for
userspace to figure out a token of their own.  Perhaps a file descriptor
certain privileged processes can pass, perhaps something else.

The bottom line is that I tend to suck at figuring out how to exploit
systems and I saw an exploit possibility with the extended privileges
you granted to CAP_SYS_BOOT nearly instantly.

I can't imagine how kernel capabilities are the right too for this kind
of job.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/