lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 10 Nov 2015 07:40:43 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Andy Lutomirski <luto@...capital.net>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Kees Cook <keescook@...omium.org>,
	Christoph Lameter <cl@...ux.com>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Richard Weinberger <richard.weinberger@...il.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks
 security in systems  using capabilities

On Tue, Nov 10, 2015 at 12:55:27PM +0100, Klaus Ethgen wrote:
> > You can tell other people that they write privileged programs in the
> > wrong programming language if you like.
> 
> Hey, it is not about programming languages. I never said something in
> that direction!
> 
> I brought python programs for a bad example in programming and how
> developers work. But that example can be made in any language. Moreover,
> as python is a script language, I would not like it at all, having any
> raised capabilities. And that is also valid for perl that I like much
> more.

And that's the fundamenal problem.  Saying that you can only be secure
if **no** scripting languages can be used for **any** privileged
operations is something that _might_ work for you, but it doesn't work
for the 99.99999999999% of the Linux systems out there, many of which
have shell scripts to configure networking, or any host of other
things.  Arguably, it's why Posix capalities have utterly failed as
far as usage except for a very, very, very, tiny, limited market.

Scripting languages are just too fundamental to Unix and Linux
systems.  And I while I won't speak for Linus here, I suspect this is
one of the places where he'll tell you that this is a prime example of
why many security people are crazy (or in his colorful language,
M***** Monkeys).

You can, after all, simply make any computer 100% secure by the
applied use of thermite --- but the computer won't be very useful
afterwards.

If you want to create a patch, my recommendation would be to do one
that turns off ambient capabilities as a CONFIG option, and hide it
under CONFIG_EXPERT.  Or maybe adding a new securebit which disables
ambient capabilities.  Whether or not that will be acceptable
upstream, I don't know, mainly because I think a strong case can be
made that such a patch has an audience of one, and adding more
complexity here for an idea which has been time-tested over decades to
be a failure is just not a good idea.

C2 by 92!

						- Ted

P.S.  What's C2 by 92?  The only government mandate that was less
successful than GOSIP.  :-)  See
https://freedom-to-tinker.com/blog/felten/stupidest-infotech-policy-contest/#comment-15049
for more details.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ