OSDev.org

Sometimes you scare me

Brendan wrote:maybe you tell a CRON daemon to start 5 copies of you in 2 seconds time

Wouldn't this at most exhaust the resources of the job in which the CRON daemon is running?

maybe you inject key-presses into the keyboard buffer and "exit()" so that if you were started by something like bash then bash gets those key-presses and starts 2 copies of you as background jobs

This would of course require the ability to manipulate the keyboard buffer, which would be another vulnerability. But I guess it would at most exhaust the resources of the job of the bash process. Indeed, a background job should be an own job with it's own resources, but the job system should be hierarchical in the sense that if one job creates another job, the old job can only grant resources to the new one that it owns.

maybe you tell the OS that you're a file system driver for "XYZ file system" and give it a dummy disk image/file (containing several partitions formatted as "XYZ file system") and let the OS auto-mount those file systems (where each of those file systems happen to contain a dummy disk image/file containing more partitions for the OS to auto-mount, which....)

Maybe you pretend to be a driver for a USB hub (that has many "virtual USB hubs" connected, that each have...)

It looks like these ones rely on another vulnerability - telling the OS that you are a driver. Well, I don't have a good idea what to do against this vulnerability (apart from "signed drivers" or the like). But anyway, wouldn't this again be solved by hierarchical jobs, where each device driver can use at most the resources that the driver of the parent device owns?

Maybe your process is used by Apache (via. CGI) whenever someone asks for the web page "http://localhost/foo.html", where your process asks Apache for the web page "http://localhost/foo.html" itself.

That would most certainly exhaust the resources of Apache's job and thus "SDOS" (self denial of service!) the web server.

Maybe it's just a simple trojan thing - e.g. "This game needs fork permission so the client can start a server process for single-player games"

Maybe there's a way to trick the GUI into thinking that the user clicked on the "OK, let this process have fork permission" button in the dialog box; where the application's installer clicks the button before the user has time to see it

These ones would of course defeat the permission system, where processes need a fork permission. In the job based system there would be no such permission, every process may fork, provided it still has resources in its job.

XenOS wrote:I guess my favored solution would be grouping processes into "jobs", where each job has a limited amount of resources (such as memory, CPU time, maybe slots in the process table etc.). When a process which belongs to a job launches a new process, the child process by default becomes a member of the same job. A fork bomb may thus exhaust the resources of the job, but not of the whole system. Another nice feature in this model would be the ability to kill / abort a job as a whole, including all its processes. This would kill all forked processes of the bomb at once, without any chance for them to fill up freed slots by further forking.

cgroups?

TylerH wrote:cgroups?

Indeed, this seems to be the same concept. I hadn't heard this name from the context of the Linux kernel before. I found the word "job" somewhere in the context on Windows process groups and adapted it for the terminology used in my kernel.