В каких случаях могут пригодится настройки файла /etc/security/limits.conf?

Ради софта для работы со звуком, например.

Когда кто-то слишком много кушает...

Потролить школьников с форкбомбами

в таких

Для работы со звуком, вестимо. Не уверен, что это подходит под категорию «дома» или «в офисе», правда.

Программный аудитор lsat выдал рекомендацию раскомментировать значение * в файле /etc/security/limits.conf.

После изменений стало так:
* soft core 0
* hard rss 10000

После повторной проверки аудитор сообщает, что всё ОК, но советует удостовериться в правильности выставленных лимитов.

Какие лимиты предпочтительнее выставлять?

Какие лимиты предпочтительнее выставлять?

Зависит от задачи. На десктопе я ulimits вообще не трогаю.

Задача, например, такая. При компиляции софта с Гитхаба есть опасения нарваться на вредоносный обфусцированный код, который устроит локальную DOS-атаку.

Заведи пользователя и его режь, под ним пускай уже всякое ненужно. А еще лучше мусор с гитхаба в контейнере пускать. Вообще не смотрела на Qubes OS и аналоги?

Ну и, имхо, SELinux намного гибче, чем ulimits.

Я с этим файлом познакомился после того, как меня система начала бить по рукам при попытке записи больших файлов. Долго искал, в чём дело, кстати.

С Qubes OS, было дело, знакомилась. Но Qubes использует .rpm-пакеты, а мне под Debian собирать надо. Да и железо для Qubes у меня, честно говоря, слабоватое.

Основную систему отдельным пользователем или контейнерами для сомнительных экспериментов с компиляцией софта усложнять не хочется.

Виртуальная машина подойдёт для того, чтобы проверить как тот или иной софт из исходников собирается, чтобы в случае неудачи основная система не захламилась?

Предозранение от fork bomb. И, емнип, для софта, собранного без libpam, не работает.