Hi,
Probably a dumb question :).
What prevents the kprobes from being built as a module? We want to use
the kprobes on our systems, but some guys worried about potential
security problems. So it'd be great if we can enable/load kprobes as
needed and then disable/unload after using it. Is it a possible senario?
Thanks,
Namhyung
On 05/15/2012 04:24 PM, Namhyung Kim wrote:
> Hi,
>
> Probably a dumb question :).
> What prevents the kprobes from being built as a module? We want to use
> the kprobes on our systems, but some guys worried about potential
> security problems. So it'd be great if we can enable/load kprobes as
> needed and then disable/unload after using it. Is it a possible senario?
>
Kconfig prevents that:
config KPROBES
bool "Kprobes"
depends on MODULES
depends on HAVE_KPROBES
select KALLSYMS
so you can have either CONFIG_KPROBES=y or CONFIG_KPROBES=n, but not =m.
Hi,
On Tue, 15 May 2012 16:31:42 +0800, Cong Wang wrote:
> On 05/15/2012 04:24 PM, Namhyung Kim wrote:
>> Hi,
>>
>> Probably a dumb question :).
>> What prevents the kprobes from being built as a module? We want to use
>> the kprobes on our systems, but some guys worried about potential
>> security problems. So it'd be great if we can enable/load kprobes as
>> needed and then disable/unload after using it. Is it a possible senario?
>>
>
> Kconfig prevents that:
>
> config KPROBES
> bool "Kprobes"
> depends on MODULES
> depends on HAVE_KPROBES
> select KALLSYMS
>
>
> so you can have either CONFIG_KPROBES=y or CONFIG_KPROBES=n, but not =m.
Sorry for an inaccurate question, my point was "Can I change it from
'bool' to 'tristate'"?
Thanks,
Namhyung
Hi,
No, actually you can't make it as a module.$B!!(BThere are
two major reasons.
- ftrace depends on the kprobes now.
- int3 handling routine is deeply depends on
the architecture. This includes text modifying code.
Thus, if you separate the kprobes into module, that means
you need to expose more ugly interface of self modifying
for kernel modules.
(2012/05/15 17:34), Namhyung Kim wrote:
> Hi,
>
> On Tue, 15 May 2012 16:31:42 +0800, Cong Wang wrote:
>> On 05/15/2012 04:24 PM, Namhyung Kim wrote:
>>> Hi,
>>>
>>> Probably a dumb question :).
>>> What prevents the kprobes from being built as a module? We want to use
>>> the kprobes on our systems, but some guys worried about potential
>>> security problems. So it'd be great if we can enable/load kprobes as
>>> needed and then disable/unload after using it. Is it a possible senario?
BTW, I'm not sure what the potential security problems on that?
kprobes itself can be used only from kernel modules(except ftrace).
If someone compromises kernel with kernel module, he doesn't need
kprobes at all. They just can do anything they want. :)
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: [email protected]
On Tue, 15 May 2012 17:24:11 +0900, Namhyung Kim said:
> Probably a dumb question :).
> What prevents the kprobes from being built as a module? We want to use
> the kprobes on our systems, but some guys worried about potential
> security problems. So it'd be great if we can enable/load kprobes as
> needed and then disable/unload after using it. Is it a possible senario?
Any troublemaker who has the ability to set a kprobe would probably also
have theability to just re-load the module before setting the kprobe (unless
you go to a *lot* of trouble to compartmentalize the root user).
So it's not clear there's a security benefit from making it a module. If anything,
it makes it *worse* because you can then surprise a sysadmin who *thought*
they were running a KPROBES=n kernel by loading a module and turning it on...
Hi,
On Tue, 15 May 2012 21:18:25 +0900, Masami Hiramatsu wrote:
> No, actually you can't make it as a module. There are
> two major reasons.
> - ftrace depends on the kprobes now.
> - int3 handling routine is deeply depends on
> the architecture. This includes text modifying code.
>
> Thus, if you separate the kprobes into module, that means
> you need to expose more ugly interface of self modifying
> for kernel modules.
>
I see.
> (2012/05/15 17:34), Namhyung Kim wrote:
>> Hi,
>>
>> On Tue, 15 May 2012 16:31:42 +0800, Cong Wang wrote:
>>> On 05/15/2012 04:24 PM, Namhyung Kim wrote:
>>>> Hi,
>>>>
>>>> Probably a dumb question :).
>>>> What prevents the kprobes from being built as a module? We want to use
>>>> the kprobes on our systems, but some guys worried about potential
>>>> security problems. So it'd be great if we can enable/load kprobes as
>>>> needed and then disable/unload after using it. Is it a possible senario?
>
> BTW, I'm not sure what the potential security problems on that?
> kprobes itself can be used only from kernel modules(except ftrace).
> If someone compromises kernel with kernel module, he doesn't need
> kprobes at all. They just can do anything they want. :)
>
Nevermind, it seems they just worried about what they don't know
exactly. Anyway, thanks for your answer.
Namhyung
Hi,
On Tue, 15 May 2012 15:52:15 -0400, valdis kletnieks wrote:
> On Tue, 15 May 2012 17:24:11 +0900, Namhyung Kim said:
>> Probably a dumb question :).
>> What prevents the kprobes from being built as a module? We want to use
>> the kprobes on our systems, but some guys worried about potential
>> security problems. So it'd be great if we can enable/load kprobes as
>> needed and then disable/unload after using it. Is it a possible senario?
>
> Any troublemaker who has the ability to set a kprobe would probably also
> have theability to just re-load the module before setting the kprobe (unless
> you go to a *lot* of trouble to compartmentalize the root user).
>
> So it's not clear there's a security benefit from making it a module. If anything,
> it makes it *worse* because you can then surprise a sysadmin who *thought*
> they were running a KPROBES=n kernel by loading a module and turning it on...
Right, thanks for your comment.
Namhyung