Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261185AbTEKUbt (ORCPT ); Sun, 11 May 2003 16:31:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261199AbTEKUbt (ORCPT ); Sun, 11 May 2003 16:31:49 -0400 Received: from siaag2af.compuserve.com ([149.174.40.136]:7563 "EHLO siaag2af.compuserve.com") by vger.kernel.org with ESMTP id S261185AbTEKUbs (ORCPT ); Sun, 11 May 2003 16:31:48 -0400 Date: Sun, 11 May 2003 16:39:37 -0400 From: Chuck Ebbert <76306.1226@compuserve.com> Subject: Re: The disappearing sys_call_table export. To: Yoav Weiss Cc: Linux Kernel Mailing List , Terje Eggestad , Ahmed Masud , "arjanv@redhat.com" Message-ID: <200305111642_MC3-1-3868-F544@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1423 Lines: 29 Yoav Weiss wrote: > No one specified what audit_log does in this case. Usually, in such > modules, the audit function doesn't just log everything. It can, for > example, rate-limit the logging and just spit a message about the user > DoSing the log system. Not on the systems I've seen. Max log file size is 4GB and the logs are on their own partition. If the file fills up the system crashes immediately and only administrators can log in after reboot until the logs are archived. > The usermode code can change it and > change it back as soon as the file has been unlinked. If the system is > under heavy load (generated by the attacker), the attacking process is > reniced to 20, and the monitoring part of it has higher priority and keeps > stat(2)ing the file, a thread in the attack code may actually be able to > change the filename back in time for the second check. Yes, but now any unsuccessful attempts to change the name will be logged, where before there was basically no risk for the attacker trying over and over until success. Even a single failure could raise an alert on the target machine, something a cracker definitely does not want to happen. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/