Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261798AbTEKRlA (ORCPT ); Sun, 11 May 2003 13:41:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261807AbTEKRlA (ORCPT ); Sun, 11 May 2003 13:41:00 -0400 Received: from corky.net ([212.150.53.130]:43198 "EHLO marcellos.corky.net") by vger.kernel.org with ESMTP id S261798AbTEKRk7 (ORCPT ); Sun, 11 May 2003 13:40:59 -0400 Date: Sun, 11 May 2003 20:53:34 +0300 (IDT) From: Yoav Weiss X-X-Sender: yoavw@marcellos.corky.net To: Chuck Ebbert <76306.1226@compuserve.com> Cc: "arjanv@redhat.com" , Ahmed Masud , Terje Eggestad , Linux Kernel Mailing List Subject: Re: The disappearing sys_call_table export. In-Reply-To: <200305111234_MC3-1-3865-CD21@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2103 Lines: 50 On Sun, 11 May 2003, Chuck Ebbert wrote: > That code has another hole that nobody else has mentioned > yet: I can fill the audit log by trying to delete nonexistent files, > and if accused of trying to mount a DOS attack on the audit trail > I can reasonably claim that it was all an accident... 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. If system is paranoid enough to be fail-closed (i.e. fears that the user is hitting the rate-limit of the logger, hoping to cover his real acts), it can always kill his task, kill all his processes, lock his account, call the authorities, etc. Its up to the system to decide what audit_log does, just like in any other auditing system. > > How about: > > long wrapped_unlink(char *userfilename) > { > char name1[len], name2[len]; > long ret; > > copy_from_user(name1, userfilename, ...); > ret = original_unlink(userfilename); > copy_from_user(name2, userfilename, ...); > > if (strncmp(name1, name2, len)) > audit_log(name1, name2, UNLINK_NAME_CHANGED); Still subject to a timing attack. 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. The only way to avoid these races is to have just one copy, by either using set_fs (see my previous post in this thread) or by hooking inside the syscall (as LSM does). Yoav Weiss - 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/