vm.swap_reserved toooooo large?

[George Mamalakis]

On 16/12/2010 18:56, Oliver Fromme wrote:
> George Mamalakis<mamalos at eng.auth.gr>  wrote:
>   >  My dmesg shows:
>   >
>   >  pid 1732 (npviewer.bin), uid 1001: exited on signal 11 (core dumped)
>   >  pid 2227 (npviewer.bin), uid 1001: exited on signal 11 (core dumped)
>   >  swap zone exhausted, increase kern.maxswzone
>   >  pid 1544 (console-kit-daemon), uid 0, was killed: out of swap space
>   >  swap zone exhausted, increase kern.maxswzone
>   >  pid 2864 (memory), uid 1001, was killed: out of swap space
>   >  swap zone exhausted, increase kern.maxswzone
>   >  pid 1676 (gconf-helper), uid 1001, was killed: out of swap space
>   >
>   >  where one can see that pid 1544 was killed before 2864, which is the
>   >  process that caused all this mess. Yes, I know that I should use limits
>   >  so as not to allow such things to happen, but on the other hand, if a
>   >  malicious user causes such a situation he/she may gain access to
>   >  information through core-dumps on root processes, AND cause DoS attacks.
>
> No.  First, when the kernel kills processes because it runs
> out of swap space, it uses SIGKILL which does _not_ cause
> a core dump to be written.  Second, core dumps are always
> created with permissions 0600, i.e. they are only readable
> by the owner of the process.
>
> Of course, any user who can run a machine out of memory can
> cause a DoS attack by doing this.  That's the reason why
> resource limits exist.
>
>   >  If it were for me, I would sort all processes based on their memory
>   >  consumption, and start by killing those that have the highest value
>   >  (top-bottom) that are NOT owned by root (just a thought, without
>   >  thinking about it too much), so as to prevent such situations from
>   >  happening.
>
> It is very non-trivial to find a generic algorithm that
> kills the "right" process in such a situation.  For example,
> an attacker could start a lot of small processes that
> allocate memory.  That's the reason why an admin should
> always configure resource limits approprately.  The kernel's
> killing feature should only be regarded as the very last
> emergency break, which basically exists only to prevent a
> reboot.
>
> If you're interested, you can find the selection algorithm
> for processes to kill in the vm_pageout_oom() function in
> src/sys/vm/vm_pageout.c.  Basically, it selects the process
> that consumes the most physical memory (RAM + swap), not
> counting the virtual size of the process.  Also, some
> processes are excluded, such as system processes and
> protected processes (cron and sshd, for example).
>
> Best regards
>     Oliver
>
Oliver, thanx for your comments. I know it is difficult to choose which 
process to kill and how to be "fair" during such a killing procedure. 
Nevertheless, I would assume that all non-root processes would have 
higher priority to get killed, and that root's processes would get 
killed last. I understand your comments completely, but I was just so 
surprised when I realized how easy it was for me to kill root processes 
on my system.

Thanx again and best regards!

mamalos

-- 
George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379