Message-ID: <5640EDB4.70407@gmail.com>
Date:	Mon, 9 Nov 2015 14:02:12 -0500
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	"Serge E. Hallyn" <serge@...lyn.com>,
	Theodore Ts'o <tytso@....edu>,
	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 4.3 breaks security in systems using
 capabilities

On 2015-11-09 12:23, Klaus Ethgen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Am Mo den  9. Nov 2015 um 17:28 schrieb Austin S Hemmelgarn:
>>> Having some scripts in the process is definitively a nightmare to
>>> control. That should be prevented wherever possible. And usually it is
>>> as the scripts might be used for computing some values that are used
>>> later in privileged stuff.
>> It's still unavoidable in a number of cases.  It's easy to re-write scripts
>> to fit any local configuration.  It's not anywhere near as easy to re-write
>> a compiled program to account for any local configuration.
>
> I would not only say that it is avoidable, it is the worst that can
> happen.
Scripts will always be necessary unless you have a purpose built system 
that never gets updated or relocated, and never has any changes to the 
hardware (and guess what, you use scripts constantly if you use the 
command-line, option syntax and configuration files are technically 
domain-specific scripting languages).
>
> Usually a shell is calling a binary to do the real work. So it should
> even never ever needed to have some raised privileges for the shell.
Unless you need the binary to be run with some privileges and can't 
reasonably use capabilities on it (for example, it's a lot of work to 
maintain a system with no set{u,g}id binaries on it and keep the 
software up-to-date on it as well).
>
>>> Good example are all that userspace python tools that throw all that
>>> stack traces around the users ears (I don't know if that saying exists
>>> in English...) instead of giving proper error messages.
>> This is debatable.  While the app should be giving a user friendly error
>> message, getting a stack-trace and the exception name (and the exceptions
>> are usually sanely named) is still far better than just getting something
>> like 'Segmentation Fault', or just returning the error in the return code.
>> There is no added security from not providing the stack-trace because there
>> is no data leaked by it (it contains no information about the contents of
>> variables, and function names and included libraries can easily be seen by
>> just looking at the python program itself).
>
> My pointing to that python problem is not about security then about how
> lazy some developer are. And lazyness and security is nothing that can
> go together.
That depends on what you mean by lazy.  Scripts can't do core-dumps 
(there is no practical way to do a core-dump from a script and still be 
reasonably easy to debug), so they have to do something to provide data 
so developers can debug it.  By having such things just dump a 
stacktrace, the developers are making it easier for stuff like ABRT and 
whatever Ubuntu uses for automated bug reporting to actually report 
things, which in turn makes handling bug reports more efficient (and a 
desire for efficiency is _not_ the same as being lazy).
>>> By the way, guys, can we start to _not_ add every one in this discussion
>>> to the Cc? Currently I get every mail twice. One from the list and one
>> >from Cc. I still leave all Ccs intact with this mail but I would prefer
>>> to just reply to the list. If anybody is not reading the list and would
>>> like to get the mail, please insist.
>> If you're getting duplicates with the same Message-ID header, then your
>> mail-server is (arguably) broken.
>
> I do not know any mailserver that cares about message-ids. Even more,
> which one is the original one if they differ in body? (as they do for
> example in this list.)
>
> It it even more broken as some (surely broken) MUAs reuse message ids.
>
>> It should be delivering exactly one copy of a message with a given
>> Message-ID: header (this is really a de-facto standard,
>
> I wouldn't say so.
The Message-ID header is supposed to be unique for the lifetime of the 
message (which effectively means almost forever for stuff on LKML, as 
it's archived).  If you are getting multiple copies of a message with 
the same Message-ID header and different content in the message, then 
something is very broken, and if a MUA is reusing Message-ID's, then 
someone needs to file a bug against that MUA.



Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)

Powered by blists - more mailing lists