linux-kernel - Re: [PATCH] emit logging when a process receives a fatal signal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <200611181146.kAIBkW52028010@harpo.it.uu.se>
Date:	Sat, 18 Nov 2006 12:46:32 +0100 (MET)
From:	Mikael Pettersson <mikpe@...uu.se>
To:	folkert@...heusden.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] emit logging when a process receives a fatal signal

On Sat, 18 Nov 2006 02:09:46 +0100, Folkert van Heusden wrote:
>I found that sometimes processes disappear on some heavily used system
>of mine without any logging. So I've written a patch against 2.6.18.2
>which emits logging when a process emits a fatal signal.
>
>Signed-off-by: Folkert van Heusden <folkert@...heusden.com>
>
>--- linux-2.6.18.2/kernel/signal.c	2006-11-04 02:33:58.000000000 +0100
>+++ linux-2.6.18.2.new/kernel/signal.c	2006-11-17 15:59:13.000000000 +0100
>@@ -706,6 +706,15 @@
> 	struct sigqueue * q = NULL;
> 	int ret = 0;
> 
>+	if (sig == SIGQUIT || sig == SIGILL  || sig == SIGTRAP ||
>+	    sig == SIGABRT || sig == SIGBUS  || sig == SIGFPE  ||
>+	    sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
>+	    sig == SIGSYS  || sig == SIGSTKFLT)
>+	{
>+		printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
>+			sig, t -> pid, t -> uid, t -> gid, t -> comm);
>+	}
>+
> 	/*
> 	 * fast-pathed signals for kernel-internal things like SIGSTOP
> 	 * or SIGKILL.

NAK.

1. It lets any user DOS the system.
2. Your definition of "fatal" signals is wrong. Several of these
   signals can be caught, and user-space sometimes does that for
   good reason. FPE and SEGV are definitely often caught, BUS and
   ILL may be caught, and I suspect TRAP to be common in debugging
   sessions.
3. It puts policy in the kernel. Policy decisions belong in user-space.
   In this case, the policy decision is whether this type of logging
   is desired for a given process or not.
4. If this is about detecting the loss of specific processes
   (network services say), then the problem can be solved in
   user-space by using a separate monitor process, or by
   controlling the processes via ptrace.

At a minimum, the logging needs to be conditionalised on a
per-process setting, and it should also be delayed until the
point where a signal causes a process to be killed.

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/