Securing a system with limits.conf

Securing a system with limits.conf

[Lasse Kärkkäinen]

I'm not sure if this is off-topic for linux-kernel but here it goes...

After doing some research (Googling, checking Hardening Linux, Essential 
System Administration and a number of other books) I was quite shocked 
that configuring the limits doesn't seem to be documented anywhere. 
Sure, they all list the information that can be acquired by ulimit -a or 
man limits.conf but those oneliner descriptions of options fail to describe:

- What does the setting actually limit (one can find what the data 
segment or a core file is by Googling but it would be nicer if the 
documentation listed the security implications of each setting).

- What is the scope of the limit: per-user, per-process, all descendants 
of the current process, ...?

- How should things be configured to reliably prevent non-priveleged 
users from DoS'ing a machine.

Is there possibly some documentation that I have not found or is there 
actually a huge gap in the essential security documentation here?

Thanks.

Re: Securing a system with limits.conf

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

On Sun, 26 Jul 2009 07:10:41 +0300, =?ISO-8859-1?Q?Lasse_K=E4rkk=E4inen?= said:

> - How should things be configured to reliably prevent non-priveleged 
> users from DoS'ing a machine.

This depends on your threat model.  What are you trying to defend against:

1) Clued user doing something stupid on their laptop?
2) Unclued user doing the same?
3) Clued user who just got bitten by an exploit in Firefox?
4) Clued user doing something stupid on a large database/web server?
5) Malicious user on a multi-user timesharing system?

bash$ :(){ :|:&};:

Consider the above line of bash code, in each of the 5 scenarios. Same
attack, but the configuration settings you use to deal with it may be
vastly different.

Now repeat the analysis, but assume you have a determined attacker who has
acquired access to *3* different logins on the machine and can use them
simultaneously, in collusion.  Now try to come up with a solution that
doesn't annoy the 3 users in question when they're legitimately logged on.

Bottom line: At best, you can make it more difficult for a local user to DoS
the box.  You can't *prevent* it unless you're willing to impose a lot of
limits your users won't like.

And sometimes, the correct security tool is not a system tunable setting,
but a baseball bat.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]