Assuming the attacker has the privileges to call su and want to elevate privileges but does not have the ability to read /etc/shadow file or otherwise obtain the hashes, then they would have to perform an online attack.

Are offline attacks against linux user account passwords possible?

No. An attacker would need to either elevate privileges, bypass permissions to read the shadow file, or in some way leak its contents. On older systems, the password hashes would be stored in /etc/passwd which is world-readable. That made offline attacks possible. On modern systems with a shadow file, only executables that are setuid like su are able to safely read the root-readable /etc/shadow and use that to decide whether or not to run a command under a different user on behalf of the caller.

When are strong linux user account passwords required?

Are strong linux account passwords required?

If by "strong" you mean strong enough to resist offline attacks, then it would only be required if those threads are part of your threat model. There's generally no downside to using stronger passwords.

How many password can an attacker try against linux user accounts per second or per minute?

This depends on the system's configuration. The delay is artificial and can be configured. For su, this can be adjusted by login.defs(5) where the variable FAIL_DELAY can be set. Systems using PAM can use the pam_fail_delay(3) module instead. Other PAM modules can customize authentication behavior further.

How many password can an attacker try against linux user accounts per second or per minute?

As many as they are allowed. In practice, this will be limited to the number of concurrent su processes that can be run, as each process will be seriously delayed. Each failed login attempt will be logged.

Can passsword bruteforcing against linux user account passwords be parallelized by the attacker and is bruteforcing only bound by the attackers available resources of CPU/RAM/etc.?

Or is passsword bruteforcing against linux user account passwords limited by su/pam or something? Can only be a limited number of passwords per second or per minute be tested?

The limiting factor will be number of processes that user is allowed to spawn. Each process itself will be limited by its configuration.

Can su/pam/everything be added a (longer and longer becoming) delay when trying a wrong password to slow down bruteforce attacks?

Yes, as described above.

How many random characters or dice words must a linux user account password have to be very secure? Are these the same requirements as for very secure FDE passwords or lower due to offline attacks not being possible against linux user account passwords?

The password does not need to be nearly as long if there is no risk of the attacker obtaining the password hash. Assuming each su invocation takes 3 seconds for a passphrase and the attacker is running 10,000 concurrent processes, that's still only 30,000 passwords per second. A 7 character alphanumeric passphrase would hold up for one year on average, which is more than enough time to stop the attack, assuming you check your logs more than once a year.

Let's assume three possible attack scenarios where the attacker is running a local process:

(1) The attacker exploits a privilege escalation vulnerability

In this circumstance, the attacker can change their UID on their own. They don't need to brute force any password. The best defense against this is to have a hardened, up-to-date system.

(2) The attacker has access to the password hashes

If the attacker can read the password hashes directly, either because they've exploited a bug that allows them to read /etc/shadow (or a vulnerable process that has access to it), or because they are attacking an outdated system that still keeps passwords in the world-readable /etc/passwd, then they'll be able to perform an offline brute force attack. They could either perform the attack on the victim system, or transmit the hashes to a more powerful system (or cluster) to offload power.

Protecting against this requires using a strong password, as they will be able to authenticate as soon as they calculate the correct password. The password can be further strengthened by using multiple rounds of hashing. This can be configured with the pam_unix(8) option rounds=n.

You can additionally enforce a strict password expiration policy. This is one of the few circumstances in which such a thing would actually be warranted and is not security theater. It would allow for slightly weaker passwords to be used safely. If a password takes on average 2 years to break, it would be considered very weak. If the password is changed every month, the attacker will be wasting a lot of time trying to break a password that will no longer be valid by the time they crack it.

(3) The attacker is in %wheel or otherwise is permitted to use su

In this case, all the attacker can do is perform an online brute force attack. They will be limited by the number of concurrent processes they can spawn, as well as the artificial delay imposed by each login process. For su, this can be configured by setting the FAIL_DELAY variable in login.defs(5). If the system is using PAM, the pam_fail_delay(3) module can be used instead.

The password does not need to be nearly as strong in this case. Assuming each su invocation takes 3 seconds for a passphrase and the attacker is running 10,000 concurrent processes, they're still only limited to 30,000 passwords per second. A 7 character alphanumeric passphrase would hold up for one year on average, which is more than enough time to stop the attack, assuming you check your logs more than once a year. A system with 10,000 su processes all failing is very noisy...