1

This can be considered a follow up to Do randomized PIDs bring more security?

A major problem with random PIDs is that they repeat more quickly than sequential PIDs, but in cryptography, we can permute sequential PIDs with a secret key in such way that no one can predict it, essentially making it appear random - in an actual OS kernel, this key would be under system protection.

Next, for initial ~100 PIDs that're have reserved meanings (e.g. 1 for init and a few others for system processes), we can just reject a PID if it fall in that range - this is as if a process with that PID started, died, and then reborn with a different PID.

Q: is this idea adopted anywhere? are there other downsides of random PIDs not solved by generating them deterministically?

Improve this question
6
  • @SteffenUllrich You had me. I just realized that even if PIDs are randomized, they can still be looked up with normal priviledges on most systems. Commented May 31, 2025 at 4:14
  • 2
    The answer in the linked question already explains which common OS supports randomized PIDs and how they implement it. This should already answer your first question. Besides that, randomized PIDs are an obscure feature that doesn't have any well-defined benefits and has clearly failed to gain any traction in the OS world. Before you jump to optimizations, you should first explain why exactly you think randomized PIDs are even beneficial. Right now, this looks like a solution looking for a problem. Commented May 31, 2025 at 4:27
  • "This should already answer your first question." not necessarily I think. I'm asking which OS uses a keyed permutation over incrementing sequences. "explain why exactly you think randomized PIDs are even beneficial." I'll look into this part, thanks. @Ja1024 Commented May 31, 2025 at 4:36
  • The answer does address your question: No common OS uses permutations, most don't even have randomized PIDs. Commented May 31, 2025 at 4:40
  • 1
    major problem with random PIDs is that they repeat more quickly than sequential PIDs no it is not. How is it a problem? What is the impact and severity? Commented May 31, 2025 at 6:39

3 Answers 3

Reset to default
3

A major problem with random PIDs is that they repeat more quickly than sequential PIDs

First I doubt that this is even a "major" problem in the real world as you claim. OpenBSD has used randomized pids since 1997, which suggests that it seems to work without causing major problems.

Apart from that your proposal does not properly address the problem. Using a random permutation of the pid space only makes sure that one pid does not get selected shortly after it already got selected, i.e. after a process with this pid has STARTED. The problem which would need to be adressed instead is to make sure that one pid does not get selected again shortly after the process owning this pid has FINISHED. Since the time a process runs can be from a few milliseconds to many many days just looking at the start time is also not a reliable approximation.

Instead one would need to have something similar to how TCP/IP ports are selected: a random port is selected from a specific range and it is checked that this port is not currently in use and was also not recently freed. To do this a list of recently closed ports is maintained.

Improve this answer
12
  • 1
    @DannyNiu: Pid 1 is reserved for init on all UNIX systems I know of. And how exactly do you want something to be random but not repeating within a specific time by not defining some kind of window where it should not be repeated? That's the window I was referring to. Commented May 31, 2025 at 4:26
  • 1
    @SteffenUllrich: The OP just wants to reserve a couple of PIDs, so that they won't be used for normal processes. Then they want to do a random permutation of the remaining numbers and use them as PIDs which are both random and non-repeating. Commented May 31, 2025 at 4:38
  • 1
    @Ja1024: Reservation of some PIDs for a specific purpose is IMHO a separat issue from the randomization and has nothing to do with what the OP has declared a "major problem" - the reuse of recently "freed" pid. And from my understanding the OP explicitly wants to prevent the reuse of recently freed pid, which basically means to have some kind of window (no matter how it is implemented) to prevent too quick reuse. This window is likely not in actual "time" but in number of processes allocated. Commented May 31, 2025 at 5:52
  • 1
    @DannyNiu: I don't mention a "time" window, just a window - which is more likely in the number of processes generated. But the problem you declare a major comes from pid to be reused within a short time frame - which is real time here. So having many processes created within a short time (which can be common as I explained) would mean that pid might be too quickly reused (in the scope of your problem) even with some kind of minimum number of processes (window) before a pid can be reused. Commented May 31, 2025 at 5:57
  • 3
    @DannyNiu: I've reworked my answer. I think the main problem with your approach is that you don't actually prevent pid reuse after the process got finished but instead after the process got started, i.e. addressing the wrong issue. Commented May 31, 2025 at 8:29
1

No. This is not a problem that needs to be solved.

Additionally, the most common endpoint platform (Windows) does not have purely sequential or random PIDs. It starts by using PIDs sequentially, however as processes exit the PID is reused. This is a different model that is ignored by your conjecture.

This sequential reuse approach has evolved into a useful source of data when identifying types of resource utilization depletion and performance issues. This is due to a Windows system that has very high process ID numbers may have a resource utilization problem (including malware) that prevents PID reuse and manifests as high process IDs.

Attempts to proceed beyond conjecture would be met with resistance to binning a useful source of data for solving problems and answering questions.

Improve this answer
1
  • In some ways this model could actually be more secure against PID reuse than pure sequential, because it causes PID reuse to be extreamly common, and quickly grabbed, this has two effects 1) It means any software that incorrectly depends on PIDs not beign reused is more likely to fail observably and be patched, 2) The OS is likely to assign the PID to something other than what the attack wants before the attacker does, making attacks harder to pull off. Commented Jun 1, 2025 at 1:24
-1

The 1st part of this answer will advocate developers not to rely on system hardening (such as PID randomization) for sole protection.

Some obsolete programs relied on PIDs as entropy source (credit goes to commentator Steffen Ullrich who provided insight under this post). Randomizing the PID provided ineffective solution to this for the obvious reason that PIDs are mostly 32-bit - very insufficient amount entropy can be provided from this. Some other non-solutions by random PIDs are mentioned in the answer to the linked Q in the OP.

The true solution to these problems, is fixing the application. Consider these:

  1. For external attackers, PIDs needn't and shouldn't be exposed in the first place. Uniqueness isn't the only requirement for an identifier for a session between a server and a client, see relevant OWASP cheatsheet topic on this.

  2. For internel attackers that can query the PIDs of processes, they shouldn't enter your system in the first place, or when they do, they should be sandbox and constrained. For example file uploads should be virus-scanned; code and command injection should be prevented.

  3. For attackers stuck on the wall, ... :p. just shoot them with a riffle.

There are however downsides of random PIDs in terms of usability:

  1. It makes the order of program start obscure,
  2. it makes typing PIDs harder,
  3. it makes reading PIDs in logs difficult.

The 2nd part discuss status quo on the specific topic of research of PID randomization as mitigation of exploits.

I checked these outlets from OpenBSD, they seem to realize that randomized PIDs aren't as great an idea as it seemed, so they might have retracted relevant papers. Regardless whether or not they did, I can't seem to find the info.

Search engines are slow on this, info exist but no discussion of merit. AI augmented chatbots cites the linked Q in the OP as information source, but only facts about implementations and no concensus on whether random PIDs are beneficial. And there seem to be very few research paper on this as well, even when I set time range to 1995-2010.

As the 3rd part, answering the question in the title:

Does deterministically random PIDs solve the problems of truely random PIDs?

From comment:

Similar with many other hardening measures which don't fix the actual problem but just make it harder to exploit.

to address the effectiveness of my idea, permuted PIDs have one-to-one mapping with incrementing sequences, so at worst they're not worse than incrementing PIDs, so technically speaking, it does improve over true random PIDs, which suffer from collision due to birthday paradox.

The problem of new processes accidentally receive a signal from an old process that mistake them as someone else is a bigger problem in reality. As suggested by Steffen Ullrich, we can take inspiration from the TCP/IP stack:

To do this a list of recently closed ports is maintained.

I called this "dead process retention" in discussion with him, and suggested retention can be limited in duration, or total number of dead processes. But this Q is about random PIDs, so that'll be the scope for another post.

Improve this answer
8
  • 3
    "There's a false premise that truely random PIDs originally solved problems. Why is it false?" - your argumentation is basically that it did not solve problems since any problems relevant for random pids should have been adressed by other measures. This is like claiming that ASLR does not solve problems since the real issue are buggy applications which need to be fixed. Similar with many other hardening measures which don't fix the actual problem but just make it harder to exploit. It would be different if random pids are useless for what they claim to be useful - but you don't address this. Commented May 31, 2025 at 11:13
  • Apart from that you don't actually answer your own problem - which is about your idea on still using random pid but avoiding what you claim (but not actually show) to be a major problem. Your answer here does not address the effectiveness of your idea, but instead tries to argue that the whole idea of random pid is wrong. Commented May 31, 2025 at 11:19
  • @SteffenUllrich addressed a bit Commented May 31, 2025 at 11:49
  • 1
    I'm not claiming that random pid are actual (still) useful. I only say that your arguments are wrong. You don't even consider what problem/attacks random pid were intended to solve. A possible explanation gives isopenbsdsecu.re/mitigations/pid_rand: "Back in the days, software developers used to use things like pid as a source of entropy, …". With this explanation the problem was not exposing the pid but using a kind of predictable value for seeding a RNG - like proposed in stackoverflow.com/a/23146999/3081018 . So it is more about hardening insecure code. Commented May 31, 2025 at 12:13
  • 1
    So you changed it from "false premise" to "false assumption .. but debated"? Looks like for me like a contradiction, either it is clearly false or it is debated. Apart from that you mention that some claim "that it originally solved problems" but don't actually mention which problems it was claimed to solve (whiich could then be the basis for arguing if it actually does solve these problems or if these were relevant problems) while instead arguing about some problems it does not solve but probably never was intended to solve. Commented May 31, 2025 at 12:42

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.