Can I block a new process execution using Kprobe?












1















Kprobe has a pre-handler function vaguely documented as followed:



User's pre-handler (kp->pre_handler)::

#include <linux/kprobes.h>
#include <linux/ptrace.h>
int pre_handler(struct kprobe *p, struct pt_regs *regs);

Called with p pointing to the kprobe associated with the breakpoint,
and regs pointing to the struct containing the registers saved when
the breakpoint was hit. Return 0 here unless you're a Kprobes geek.


I was wondering if one can use this function (or any other Kprobe feature) to prevent a process from being executed forked.










share|improve this question





























    1















    Kprobe has a pre-handler function vaguely documented as followed:



    User's pre-handler (kp->pre_handler)::

    #include <linux/kprobes.h>
    #include <linux/ptrace.h>
    int pre_handler(struct kprobe *p, struct pt_regs *regs);

    Called with p pointing to the kprobe associated with the breakpoint,
    and regs pointing to the struct containing the registers saved when
    the breakpoint was hit. Return 0 here unless you're a Kprobes geek.


    I was wondering if one can use this function (or any other Kprobe feature) to prevent a process from being executed forked.










    share|improve this question



























      1












      1








      1








      Kprobe has a pre-handler function vaguely documented as followed:



      User's pre-handler (kp->pre_handler)::

      #include <linux/kprobes.h>
      #include <linux/ptrace.h>
      int pre_handler(struct kprobe *p, struct pt_regs *regs);

      Called with p pointing to the kprobe associated with the breakpoint,
      and regs pointing to the struct containing the registers saved when
      the breakpoint was hit. Return 0 here unless you're a Kprobes geek.


      I was wondering if one can use this function (or any other Kprobe feature) to prevent a process from being executed forked.










      share|improve this question
















      Kprobe has a pre-handler function vaguely documented as followed:



      User's pre-handler (kp->pre_handler)::

      #include <linux/kprobes.h>
      #include <linux/ptrace.h>
      int pre_handler(struct kprobe *p, struct pt_regs *regs);

      Called with p pointing to the kprobe associated with the breakpoint,
      and regs pointing to the struct containing the registers saved when
      the breakpoint was hit. Return 0 here unless you're a Kprobes geek.


      I was wondering if one can use this function (or any other Kprobe feature) to prevent a process from being executed forked.







      linux security callback linux-kernel kprobe






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 24 '18 at 15:21







      David Ariel

















      asked Nov 24 '18 at 11:35









      David ArielDavid Ariel

      1709




      1709
























          1 Answer
          1






          active

          oldest

          votes


















          2














          As documented in the kernel documentation, you can change the execution path by changing the appropriate register (e.g., IP register in x86):



          Changing Execution Path
          -----------------------

          Since kprobes can probe into a running kernel code, it can change the
          register set, including instruction pointer. This operation requires
          maximum care, such as keeping the stack frame, recovering the execution
          path etc. Since it operates on a running kernel and needs deep knowledge
          of computer architecture and concurrent computing, you can easily shoot
          your foot.

          If you change the instruction pointer (and set up other related
          registers) in pre_handler, you must return !0 so that kprobes stops
          single stepping and just returns to the given address.
          This also means post_handler should not be called anymore.

          Note that this operation may be harder on some architectures which use
          TOC (Table of Contents) for function call, since you have to setup a new
          TOC for your function in your module, and recover the old one after
          returning from it.


          So you might be able to block a process' execution by jumping over some code. I wouldn't recommend it; you're more likely to cause a kernel crash than to succeed in stopping the execution of a new process.



          seccomp-bpf is probably better suited for your use case. This StackOverflow answer gives you all the information you need to leverage seccomp-bpf.






          share|improve this answer























            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53457705%2fcan-i-block-a-new-process-execution-using-kprobe%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            2














            As documented in the kernel documentation, you can change the execution path by changing the appropriate register (e.g., IP register in x86):



            Changing Execution Path
            -----------------------

            Since kprobes can probe into a running kernel code, it can change the
            register set, including instruction pointer. This operation requires
            maximum care, such as keeping the stack frame, recovering the execution
            path etc. Since it operates on a running kernel and needs deep knowledge
            of computer architecture and concurrent computing, you can easily shoot
            your foot.

            If you change the instruction pointer (and set up other related
            registers) in pre_handler, you must return !0 so that kprobes stops
            single stepping and just returns to the given address.
            This also means post_handler should not be called anymore.

            Note that this operation may be harder on some architectures which use
            TOC (Table of Contents) for function call, since you have to setup a new
            TOC for your function in your module, and recover the old one after
            returning from it.


            So you might be able to block a process' execution by jumping over some code. I wouldn't recommend it; you're more likely to cause a kernel crash than to succeed in stopping the execution of a new process.



            seccomp-bpf is probably better suited for your use case. This StackOverflow answer gives you all the information you need to leverage seccomp-bpf.






            share|improve this answer




























              2














              As documented in the kernel documentation, you can change the execution path by changing the appropriate register (e.g., IP register in x86):



              Changing Execution Path
              -----------------------

              Since kprobes can probe into a running kernel code, it can change the
              register set, including instruction pointer. This operation requires
              maximum care, such as keeping the stack frame, recovering the execution
              path etc. Since it operates on a running kernel and needs deep knowledge
              of computer architecture and concurrent computing, you can easily shoot
              your foot.

              If you change the instruction pointer (and set up other related
              registers) in pre_handler, you must return !0 so that kprobes stops
              single stepping and just returns to the given address.
              This also means post_handler should not be called anymore.

              Note that this operation may be harder on some architectures which use
              TOC (Table of Contents) for function call, since you have to setup a new
              TOC for your function in your module, and recover the old one after
              returning from it.


              So you might be able to block a process' execution by jumping over some code. I wouldn't recommend it; you're more likely to cause a kernel crash than to succeed in stopping the execution of a new process.



              seccomp-bpf is probably better suited for your use case. This StackOverflow answer gives you all the information you need to leverage seccomp-bpf.






              share|improve this answer


























                2












                2








                2







                As documented in the kernel documentation, you can change the execution path by changing the appropriate register (e.g., IP register in x86):



                Changing Execution Path
                -----------------------

                Since kprobes can probe into a running kernel code, it can change the
                register set, including instruction pointer. This operation requires
                maximum care, such as keeping the stack frame, recovering the execution
                path etc. Since it operates on a running kernel and needs deep knowledge
                of computer architecture and concurrent computing, you can easily shoot
                your foot.

                If you change the instruction pointer (and set up other related
                registers) in pre_handler, you must return !0 so that kprobes stops
                single stepping and just returns to the given address.
                This also means post_handler should not be called anymore.

                Note that this operation may be harder on some architectures which use
                TOC (Table of Contents) for function call, since you have to setup a new
                TOC for your function in your module, and recover the old one after
                returning from it.


                So you might be able to block a process' execution by jumping over some code. I wouldn't recommend it; you're more likely to cause a kernel crash than to succeed in stopping the execution of a new process.



                seccomp-bpf is probably better suited for your use case. This StackOverflow answer gives you all the information you need to leverage seccomp-bpf.






                share|improve this answer













                As documented in the kernel documentation, you can change the execution path by changing the appropriate register (e.g., IP register in x86):



                Changing Execution Path
                -----------------------

                Since kprobes can probe into a running kernel code, it can change the
                register set, including instruction pointer. This operation requires
                maximum care, such as keeping the stack frame, recovering the execution
                path etc. Since it operates on a running kernel and needs deep knowledge
                of computer architecture and concurrent computing, you can easily shoot
                your foot.

                If you change the instruction pointer (and set up other related
                registers) in pre_handler, you must return !0 so that kprobes stops
                single stepping and just returns to the given address.
                This also means post_handler should not be called anymore.

                Note that this operation may be harder on some architectures which use
                TOC (Table of Contents) for function call, since you have to setup a new
                TOC for your function in your module, and recover the old one after
                returning from it.


                So you might be able to block a process' execution by jumping over some code. I wouldn't recommend it; you're more likely to cause a kernel crash than to succeed in stopping the execution of a new process.



                seccomp-bpf is probably better suited for your use case. This StackOverflow answer gives you all the information you need to leverage seccomp-bpf.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 24 '18 at 17:25









                pchaignopchaigno

                3,91911127




                3,91911127
































                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53457705%2fcan-i-block-a-new-process-execution-using-kprobe%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Wiesbaden

                    Marschland

                    Dieringhausen