[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151105173438.GA3378@mail.hallyn.com>
Date: Thu, 5 Nov 2015 11:34:38 -0600
From: "Serge E. Hallyn" <serge@...lyn.com>
To: Klaus Ethgen <Klaus+lkml@...gen.de>
Cc: "Serge E. Hallyn" <serge@...lyn.com>,
Andy Lutomirski <luto@...capital.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Richard Weinberger <richard.weinberger@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Christoph Lameter <cl@...ux.com>,
Andy Lutomirski <luto@...nel.org>,
Serge Hallyn <serge.hallyn@...ntu.com>,
Kees Cook <keescook@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks
security in systems using capabilities
On Thu, Nov 05, 2015 at 06:17:01PM +0100, Klaus Ethgen wrote:
> Hi Serge,
>
> Am Do den 5. Nov 2015 um 17:15 schrieb Serge E. Hallyn:
> > I think if you follow your idea to its logical conclusions, you end
> > up wanting set SECURE_ALL_BITS | SECURE_ALL_LOCKS, which will include
> > SECURE_NO_CAP_AMBIENT_RAISE, disabling ambient capabilities.
>
> That I did miss out and seems to be the solution for the problem. So
> adding cap_secure_all_bits,cap_secure_all_locks=ep to every binary that
> gets other caps should solve it?
No that doesn't work, you have to use prctl to set those bits. If you
can get your system to be fully rootless, you can have init or initramfs
do this for you. It'll mean that root and setuid-root binaries have no
automatic privileges beside owning host (proc/sys) files.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists