lkml.org 
[lkml]   [2015]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities
From
Date
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.


[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2015-11-09 21:01    [W:0.489 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site