No announcement yet.

FGKASLR Revved For Improving Linux Kernel Security

  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Danny3 View Post

    Good explanation, but the "guest leaving their faucet on and flooding the apartment underneath..." wouldn't mean that some program can behave differently than expected and try to write more than the size of the slice of memory it was given to it ?
    Can't this be controlled in a way like do not write into memory anything that more than the size you have been given an send back a message to the program to know that it has ran out of the allocated memory and what the program tried to write it was not written ?

    While in real life is very difficult to have such a control not to flood anything, but I don't see why in computers cannot have a program like the hotel manager but for memory with a few simple duties like:
    • Give each program a slice of memory and write into a table which program, location of slice and the size of it.
    • When a program asks you to write something for it in its slice of memory, check in the above table if it's the owner of that slice and if there's enough space remaining in its slice to write that, so always write the data for the program until its slice is filled, but never more.
    • When a program asks you to read something for it from its slice of memory, check in the above table if it's the owner of that slice and do it from one end to another, but never more that it has there.
    In real life it would be possible to make all the faucets not working without the hotel manager itself turning them on or of so you' have to call him every time to do this, but it would insane and nobody would stay at such hotel, but in software, I don't see much of a problem moving the responsibility from programs to a trusted manager that does what they ask if they ask sane things.
    Sorry I should have been more clear. The room underneath belongs to the hotel manager (the kernel) and the faucet being turned on is done via a syscall. Esentially you're preventing a bug in the kernel, such as buffer overflow, from causing "reproducible" spills of data.

    If the spills are reproducible you can vector your attack exploiting that "leak/bug" to get to privileged information, or as in most actual cases, cause the "manager" (kernel) to execute something in your name so to speak by spilling the right stuff out.

    Imagine it if you will as the manager getting water on his "todo list" paper causing it to smudge and then misunderstanding the instructions as "raise admin level to room holder directly above" for example

    If you randomize your "contents", it becomes practically impossible to smudge in the right way.