I'm learning about privilege escalation.

I'm trying exploits in my lab machine like vulnhub.

In my opinion, if I successfully run the exploit linux/local/udev/net_link, I can read etc/shadow and etc/passwd files. But I already have root rights, because I can read everything with meterpreter.

What rights can kernel-based exploit give me? What are these rights? I'm obviously a little confused.

  • 1
    To answer with a metaphor: Root is Gandalf the White. The kernel is Tolkien.
    – anon
    Commented Jul 11, 2019 at 17:04

2 Answers 2


I think you're confused about privilege escalation. First of all privilege escalation is meant to bypass restrictions for a low privileged user in order to execute tasks as a high (root) privileged user.

Executing a privilege escalation exploit as root is kind of useless (just to state the obvious)

What right can kernel based exploit give me

root privileges

  • Not quite true. On modern Linux systems, having uid=0 doesn’t necessarily mean you have full access to the system. Consider namespace-based containers, where the user id is only meaningful within your namespace. In that case, by attacking the kernel, you can break out of your limited namespace, because namespaces are created and maintained in the kernel. This is applicable to Docker and on the many systems allowing unprivileged users to effectively grant themselves root via creation of a new (empty) namespace, where they can then reach otherwise unreachable attack surface in the kernel
    – adam
    Commented Nov 24, 2023 at 17:38

If you have root privileges, the main reasons you might attack the kernel are:

  1. To break out of a chroot()
  2. To break out of a namespace (e.g. container)
  3. To bypass kernel-enforced restrictions designed to limit what root can do (selinux, grsecurity are the two that come to mind)


  • Defeating selinux by attacking the kernel is commonly required when exploiting Android mobile devices
  • Escaping from namespaces is obviously also a very common need as containers become more and more common
  • The use of chroot as a security boundary is not as common as it once was, because it’s much more elegant and powerful to use namespaces or namespace-based container solutions (like Docker) to isolate a process. However, it’s still a case where root is restricted by the kernel, and can only be unrestricted by code executing with kernel privileges

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .