On 16/12/2010 18:56, Oliver Fromme wrote:
George Mamalakis<mama...@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

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to