prevent module unloading

prevent module unloading

[Daniel Doron]

Hi,

i am interested in protecting some modules unloading via SystemTap. I
have contemplated modifying the name_user argument but i see it is
passed as const. So does that mean that the pointer is pointing to a
read only memory location in which case i have no way of modifying it?
I wanted to change it to some non-existing module name which would
result in an error...Or maybe there is a way to cast the const away
and modify the name....?

Ideas?


Thanks,
-Daniel.

Re: prevent module unloading

[Arkady]

Modifying syscall arguments in the SystemTap probe will not impact the
system call itself.
The krpobes copies the syscall arguments to a memory space allocated
specifically for the probe.
What the SystemTap probes see is a copy of the arguments user
application provided.

If you want to "break" a system call you need to modify internal
kernel structures or the
original syscall stack. One approach could be to change the UID in the
beginning of the rmmod
and recover the UID in the end

On Wed, Oct 18, 2017 at 11:13 AM, Daniel Doron
<danielmeirdoron@gmail.com> wrote:
> Hi,
>
> i am interested in protecting some modules unloading via SystemTap. I
> have contemplated modifying the name_user argument but i see it is
> passed as const. So does that mean that the pointer is pointing to a
> read only memory location in which case i have no way of modifying it?
> I wanted to change it to some non-existing module name which would
> result in an error...Or maybe there is a way to cast the const away
> and modify the name....?
>
> Ideas?
>
>
> Thanks,
> -Daniel.

Re: prevent module unloading

[Daniel Doron]

Brilliant! thanks Arkady :-)

On Wed, Oct 18, 2017 at 11:20 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
> Modifying syscall arguments in the SystemTap probe will not impact the
> system call itself.
> The krpobes copies the syscall arguments to a memory space allocated
> specifically for the probe.
> What the SystemTap probes see is a copy of the arguments user
> application provided.
>
> If you want to "break" a system call you need to modify internal
> kernel structures or the
> original syscall stack. One approach could be to change the UID in the
> beginning of the rmmod
> and recover the UID in the end
>
> On Wed, Oct 18, 2017 at 11:13 AM, Daniel Doron
> <danielmeirdoron@gmail.com> wrote:
>> Hi,
>>
>> i am interested in protecting some modules unloading via SystemTap. I
>> have contemplated modifying the name_user argument but i see it is
>> passed as const. So does that mean that the pointer is pointing to a
>> read only memory location in which case i have no way of modifying it?
>> I wanted to change it to some non-existing module name which would
>> result in an error...Or maybe there is a way to cast the const away
>> and modify the name....?
>>
>> Ideas?
>>
>>
>> Thanks,
>> -Daniel.

Re: prevent module unloading

[Daniel Doron]

Wondering, then how does the possibility of changing the $return value works?

On Wed, Oct 18, 2017 at 11:21 AM, Daniel Doron
<danielmeirdoron@gmail.com> wrote:
> Brilliant! thanks Arkady :-)
>
> On Wed, Oct 18, 2017 at 11:20 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
>> Modifying syscall arguments in the SystemTap probe will not impact the
>> system call itself.
>> The krpobes copies the syscall arguments to a memory space allocated
>> specifically for the probe.
>> What the SystemTap probes see is a copy of the arguments user
>> application provided.
>>
>> If you want to "break" a system call you need to modify internal
>> kernel structures or the
>> original syscall stack. One approach could be to change the UID in the
>> beginning of the rmmod
>> and recover the UID in the end
>>
>> On Wed, Oct 18, 2017 at 11:13 AM, Daniel Doron
>> <danielmeirdoron@gmail.com> wrote:
>>> Hi,
>>>
>>> i am interested in protecting some modules unloading via SystemTap. I
>>> have contemplated modifying the name_user argument but i see it is
>>> passed as const. So does that mean that the pointer is pointing to a
>>> read only memory location in which case i have no way of modifying it?
>>> I wanted to change it to some non-existing module name which would
>>> result in an error...Or maybe there is a way to cast the const away
>>> and modify the name....?
>>>
>>> Ideas?
>>>
>>>
>>> Thanks,
>>> -Daniel.

Re: prevent module unloading

[Arkady]

https://stackoverflow.com/questions/43003805/can-ebpf-modify-the-return-value-or-parameters-of-a-syscall/43030030

On Wed, Oct 18, 2017 at 11:24 AM, Daniel Doron
<danielmeirdoron@gmail.com> wrote:
> Wondering, then how does the possibility of changing the $return value works?
>
> On Wed, Oct 18, 2017 at 11:21 AM, Daniel Doron
> <danielmeirdoron@gmail.com> wrote:
>> Brilliant! thanks Arkady :-)
>>
>> On Wed, Oct 18, 2017 at 11:20 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
>>> Modifying syscall arguments in the SystemTap probe will not impact the
>>> system call itself.
>>> The krpobes copies the syscall arguments to a memory space allocated
>>> specifically for the probe.
>>> What the SystemTap probes see is a copy of the arguments user
>>> application provided.
>>>
>>> If you want to "break" a system call you need to modify internal
>>> kernel structures or the
>>> original syscall stack. One approach could be to change the UID in the
>>> beginning of the rmmod
>>> and recover the UID in the end
>>>
>>> On Wed, Oct 18, 2017 at 11:13 AM, Daniel Doron
>>> <danielmeirdoron@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> i am interested in protecting some modules unloading via SystemTap. I
>>>> have contemplated modifying the name_user argument but i see it is
>>>> passed as const. So does that mean that the pointer is pointing to a
>>>> read only memory location in which case i have no way of modifying it?
>>>> I wanted to change it to some non-existing module name which would
>>>> result in an error...Or maybe there is a way to cast the const away
>>>> and modify the name....?
>>>>
>>>> Ideas?
>>>>
>>>>
>>>> Thanks,
>>>> -Daniel.

Re: prevent module unloading

[Arkady]

Probably easier is to allow rmmod and insmod the module immediately
after that from a script.

On Wed, Oct 18, 2017 at 11:27 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
> https://stackoverflow.com/questions/43003805/can-ebpf-modify-the-return-value-or-parameters-of-a-syscall/43030030
>
> On Wed, Oct 18, 2017 at 11:24 AM, Daniel Doron
> <danielmeirdoron@gmail.com> wrote:
>> Wondering, then how does the possibility of changing the $return value works?
>>
>> On Wed, Oct 18, 2017 at 11:21 AM, Daniel Doron
>> <danielmeirdoron@gmail.com> wrote:
>>> Brilliant! thanks Arkady :-)
>>>
>>> On Wed, Oct 18, 2017 at 11:20 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
>>>> Modifying syscall arguments in the SystemTap probe will not impact the
>>>> system call itself.
>>>> The krpobes copies the syscall arguments to a memory space allocated
>>>> specifically for the probe.
>>>> What the SystemTap probes see is a copy of the arguments user
>>>> application provided.
>>>>
>>>> If you want to "break" a system call you need to modify internal
>>>> kernel structures or the
>>>> original syscall stack. One approach could be to change the UID in the
>>>> beginning of the rmmod
>>>> and recover the UID in the end
>>>>
>>>> On Wed, Oct 18, 2017 at 11:13 AM, Daniel Doron
>>>> <danielmeirdoron@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> i am interested in protecting some modules unloading via SystemTap. I
>>>>> have contemplated modifying the name_user argument but i see it is
>>>>> passed as const. So does that mean that the pointer is pointing to a
>>>>> read only memory location in which case i have no way of modifying it?
>>>>> I wanted to change it to some non-existing module name which would
>>>>> result in an error...Or maybe there is a way to cast the const away
>>>>> and modify the name....?
>>>>>
>>>>> Ideas?
>>>>>
>>>>>
>>>>> Thanks,
>>>>> -Daniel.

Re: prevent module unloading

[Daniel Doron]

BTW, the UID approach did not work for me, so I am taking the task
caps approach, i.e. removing and restoring CAP_SYS_MODULE.

Sorry, I did not get what you mean by "Probably easier is to allow
rmmod and insmod the module immediately after that from a script." ...

On Wed, Oct 18, 2017 at 5:17 PM, Arkady <arkady.miasnikov@gmail.com> wrote:
> Probably easier is to allow rmmod and insmod the module immediately
> after that from a script.
>
> On Wed, Oct 18, 2017 at 11:27 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
>> https://stackoverflow.com/questions/43003805/can-ebpf-modify-the-return-value-or-parameters-of-a-syscall/43030030
>>
>> On Wed, Oct 18, 2017 at 11:24 AM, Daniel Doron
>> <danielmeirdoron@gmail.com> wrote:
>>> Wondering, then how does the possibility of changing the $return value works?
>>>
>>> On Wed, Oct 18, 2017 at 11:21 AM, Daniel Doron
>>> <danielmeirdoron@gmail.com> wrote:
>>>> Brilliant! thanks Arkady :-)
>>>>
>>>> On Wed, Oct 18, 2017 at 11:20 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
>>>>> Modifying syscall arguments in the SystemTap probe will not impact the
>>>>> system call itself.
>>>>> The krpobes copies the syscall arguments to a memory space allocated
>>>>> specifically for the probe.
>>>>> What the SystemTap probes see is a copy of the arguments user
>>>>> application provided.
>>>>>
>>>>> If you want to "break" a system call you need to modify internal
>>>>> kernel structures or the
>>>>> original syscall stack. One approach could be to change the UID in the
>>>>> beginning of the rmmod
>>>>> and recover the UID in the end
>>>>>
>>>>> On Wed, Oct 18, 2017 at 11:13 AM, Daniel Doron
>>>>> <danielmeirdoron@gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> i am interested in protecting some modules unloading via SystemTap. I
>>>>>> have contemplated modifying the name_user argument but i see it is
>>>>>> passed as const. So does that mean that the pointer is pointing to a
>>>>>> read only memory location in which case i have no way of modifying it?
>>>>>> I wanted to change it to some non-existing module name which would
>>>>>> result in an error...Or maybe there is a way to cast the const away
>>>>>> and modify the name....?
>>>>>>
>>>>>> Ideas?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> -Daniel.

Re: prevent module unloading

[Frank Ch. Eigler]

arkady.miasnikov wrote:

> Modifying syscall arguments in the SystemTap probe will not impact the
> system call itself.  [...]

I'm not sure under in what context you mean.  We can definitely modify
system call parameters (or local variables generally) by writing to the
$context variables carrying function parameters via code like in
https://sourceware.org/systemtap/examples/#process/noptrace.stp :

[...]
probe syscall.ptrace {
   [...]
   # changing it to an invalid request number works too
   $request=0xbeef # anything invalid should do
   [...]
}
[...]

If you were referring to the script-level variables:

% stap -L syscall.ptrace
syscall.ptrace name:string request:long pid:long addr:long data:long
argstr:string $request:long int $pid:long int $addr:long int $data:long int

Then yes, modifying "name" or "request" won't do anything.  But the
underyling $context variables - yeah!


- FChE