Re: Linux kernels DoSable by file-max limit

[Michal Zalewski <lcamtuf () coredump cx>]

On Mon, 8 Jul 2002, Kurt Seifried wrote:

> For example you can limit the amount of memory that user "bob" is allowed to
> use:
>
> user          hard    memlock         4096

Uhhh... not quite. Linux kernel does not really provide a nice way of
enforcing per-user limits by default, IIRC (unless something changed in
last few years ;-). Both PAM and 'ulimit' share essentially the same
interface, setrlimit(), that is mostly per-process, not per-user. Some PAM
extensions (such as the maximum number of logins)  are enforced on a
per-user basis on a completely different layer. Even if you use PAM to set
a "memory limit for a group 'students'", you are essentially setting a
memory limit for each process of every person logged in that belongs to
this group.

And they can still most likely bypass your limit by putting something
smart in their .procmailrc / .forward / .qmail, or in so many other ways.

Linux limits are basically intended to prevent accidents from happening
(such as some clueless user testing the code I have in my signature, why
not... or a mail client gone bad and eating up all memory).

There is very little you can do to change unless you make some serious
redesign and very precise kernel and user-space time and resource control
(with something like per-user-per-day CPU time / file usage / memory usage
limits, peak usage limit, limits for whole groups of users, etc). In
general, the reasonable assumption is that your *users* would prefer to
use the system instead of rendering it unusable. If you have some mission
critical tasks on the same machine as some potentially malicious users,
split it into two separate boxes - simple. And on the box where you have
malicious users, deploy some fair time and resource sharing (perhaps a
VM?;) or simply restrict their rights to a very basic set of tools.

> core files can be created when a program crashes. They have been used in
> security exploits, overwriting system files, or by containing sensitive
> information (such as passwords).

Hm, yes and no. Linux behaves pretty well when it comes to core files -
privileged programs generally don't drop cores, cores don't follow
symlinks, etc, etc.

> Bash has built in limits, accessed via "ulimit". Any hard limits cannot be
> set higher, so if you have limits defined in /etc/profile, or in the users
> .bash_profile (assuming they cannot edit/delete .bash_profile) you can
> enforce limits on users with Bash shells.

Even if I do 'ssh user@host bash --norc --noprofile'?:-)

-- 
_____________________________________________________
Michal Zalewski [lcamtuf () bos bindview com] [security]
[http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};:
=-=> Did you know that clones never use mirrors? <=-=
          http://lcamtuf.coredump.cx/photo/