Re: [FYI] tux3: Core changes

[Daniel Phillips <daniel@phunq.net>]

On 05/27/2015 02:37 PM, Pavel Machek wrote:
> On Wed 2015-05-27 11:09:25, Daniel Phillips wrote:
>> On Wednesday, May 27, 2015 12:41:37 AM PDT, Pavel Machek wrote:
>>> On Fri 2015-05-15 02:38:33, Daniel Phillips wrote:
>>>> On 05/14/2015 08:06 PM, Rik van Riel wrote: ...
>>>
>>> Umm. Why do you think it is only issue for executable files?
>>
>> I meant: files with code in them, that will be executed. Please excuse
>> me for colliding with the chmod sense. I will say "code files" to avoid
>> ambiguity.
>>
>>> I'm free to mmap() any file, and then execute from it.
>>>
>>> /lib/ld-linux.so /path/to/binary
>>>
>>> is known way to exec programs that do not have x bit set.
>>
>> So... why would I write to a code file at the same time as stepping
>> through it with ptrace? Should I expect ptrace to work perfectly if
>> I do that? What would "work perfectly" mean, if the code is changing
>> at the same time as being traced?
> 
> Do you have any imagination at all?

[Non-collegial rhetoric alert, it would be helpful to avoid that.]

> Reasons I should expect ptrace to work perfectly if I'm writing to
> file:
> 
> 1) it used to work before
> 
> 2) it used to work before
> 
> 3) it used to work before and regressions are not allowed

Are you sure that ptrace will work perfectly on a file that you are
writing to at the same time as tracing? If so, it has magic that I
do not understand. Could you please explain.

> 4) some kind of just in time compiler

A JIT that can tolerate being written to by a task it knows nothing
about, at the same time as it is generating code in the file? I do
not know of any such JIT.

> 5) some kind of malware, playing tricks so that you have trouble
> analyzing it

By writing to a code file? Then it already has write access to the
code file, so it has already gotten inside your security perimeter
without needing help from page fork. That said, we should be alert
for any new holes that page fork might open. But if there are any,
they should be actual holes, not theoretical ones.

> and of course,
> 
> 6) it used to work before.

I look forward to your explanation of how.

Regards,

Daniel