From MAILER-DAEMON Tue Jan 18 16:17:36 2005 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Cr0jG-0007Q9-4p for mharc-dazuko-devel@gnu.org; Tue, 18 Jan 2005 16:17:34 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cr0jA-0007Mk-Dg for dazuko-devel@nongnu.org; Tue, 18 Jan 2005 16:17:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cr0j3-0007Jj-FW for dazuko-devel@nongnu.org; Tue, 18 Jan 2005 16:17:21 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cr0j3-0007JH-D4; Tue, 18 Jan 2005 16:17:21 -0500 Received: from [64.41.120.53] (helo=lva099.siteprotect.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cr0VM-0008LY-Ag; Tue, 18 Jan 2005 16:03:12 -0500 Received: from epsilon.fn.ogness.net (pD95F7236.dip.t-dialin.net [217.95.114.54]) by lva099.siteprotect.com (8.11.6/8.11.6) with ESMTP id j0IL36931408; Tue, 18 Jan 2005 15:03:09 -0600 Received: from [192.168.0.10] (johno.fn.ogness.net [192.168.0.10]) by epsilon.fn.ogness.net (8.12.8p1/8.12.8) with ESMTP id j0IL2bqT017798; Tue, 18 Jan 2005 22:02:38 +0100 (CET) (envelope-from jogness@antivir.de) Message-ID: <41ED797E.5060302@antivir.de> Date: Tue, 18 Jan 2005 22:02:54 +0100 From: John Ogness User-Agent: Mozilla Thunderbird 0.9 (X11/20041114) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dazuko-devel@nongnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dazuko-help@nongnu.org Subject: [Dazuko-devel] 2.0.5-pre4 posted X-BeenThere: dazuko-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jogness@antivir.de List-Id: dazuko-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2005 21:17:31 -0000 Hi, I have posted another pre-release of 2.0.5. The last pre-release caused a lot of problems with the __d_path() function (specifically, with vfsmount_lock). This turns out to be a much bigger problem than I first thought. The problem: __d_path(), a critical function for performing full path name lookups, is not exported to kernel modules. Dazuko could have its own copy of this function except that the function uses a kernel lock (vfsmount_lock) that is also not exported to kernel modules. The solution: On non-SMP kernels the lock is irrelevant because non-SMP kernels don't use kernel locks. This means that for non-SMP kernels, Dazuko can use an internal copy of the __d_path() function. However, SMP kernels do need kernel locks and therefore *must* use the "real" __d_path() function in the kernel. In order to do this, the __d_path() function must be exported. A very small kernel patch is now provided with the Dazuko package to export the function. For SMP kernels, this means that the kernel source must be patched and a new kernel built. I hate this as much as you do, but there is no way around it. Some distributions (such as Fedora Core) already export __d_path(), so a kernel patch/rebuild isn't necessary. Hopefully more distributions (and maybe even the "vanilla" kernel) will once again export this function. Also included in the Dazuko package is a README.linux26 file that explains this. The "configure" script also produces a warning if you have an SMP kernel and suggests reading the README.linux26 file. I am open for comments/suggestions about this. I don't know what else to do. I normally don't post these announcements to dazuko-help, but I felt that this information was important (although a bit technical). John Ogness -- Dazuko Maintainer From MAILER-DAEMON Wed Jan 19 15:42:12 2005 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1CrMb0-0004bt-CU for mharc-dazuko-devel@gnu.org; Wed, 19 Jan 2005 15:38:30 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CrMam-0004Xo-Ht for dazuko-devel@nongnu.org; Wed, 19 Jan 2005 15:38:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CrMaY-0004OJ-Ky for dazuko-devel@nongnu.org; Wed, 19 Jan 2005 15:38:02 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CrMaY-0004OG-9o for dazuko-devel@nongnu.org; Wed, 19 Jan 2005 15:38:02 -0500 Received: from [64.41.120.53] (helo=lva099.siteprotect.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CrMA8-0004RC-Q8 for dazuko-devel@nongnu.org; Wed, 19 Jan 2005 15:10:44 -0500 Received: from epsilon.fn.ogness.net (pD95F79E0.dip.t-dialin.net [217.95.121.224]) by lva099.siteprotect.com (8.11.6/8.11.6) with ESMTP id j0JKAfQ23989 for ; Wed, 19 Jan 2005 14:10:42 -0600 Received: from [192.168.0.10] (johno.fn.ogness.net [192.168.0.10]) by epsilon.fn.ogness.net (8.12.8p1/8.12.8) with ESMTP id j0JKACqT021834 for ; Wed, 19 Jan 2005 21:10:13 +0100 (CET) (envelope-from jogness@antivir.de) Message-ID: <41EEBEBB.6070009@antivir.de> Date: Wed, 19 Jan 2005 21:10:35 +0100 From: John Ogness User-Agent: Mozilla Thunderbird 0.9 (X11/20041114) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dazuko-devel@nongnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by lva099.siteprotect.com id j0JKAfQ23989 Subject: [Dazuko-devel] 2.0.5-pre5 posted X-BeenThere: dazuko-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jogness@antivir.de List-Id: dazuko-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2005 20:38:27 -0000 Hi, There were 2 minor problems with the pre4 version, so it would not work=20 if you were trying to use the kernel's built-in __d_path() function. It=20 should be working good now. By the way, all this __d_path() stuff I have been talking about only=20 applies to Linux 2.6 kernels. If you are using Linux 2.2/2.4,=20 Linux/RSBAC, or FreeBSD then this isn't an issue for you. Unless I receive problem reports within the next week, I will be=20 releas=EDng this version as the official 2.0.5. John Ogness --=20 Dazuko Maintainer From MAILER-DAEMON Thu Jan 20 09:30:03 2005 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1CrdHf-0002nm-00 for mharc-dazuko-devel@gnu.org; Thu, 20 Jan 2005 09:27:39 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CrdHR-0002fu-8g for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 09:27:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CrdHH-0002bx-TD for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 09:27:17 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CrdHH-0002Y2-4e for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 09:27:15 -0500 Received: from [193.110.109.20] (helo=fsmail-out.f-secure.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Crcxc-0000PK-B9 for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 09:06:56 -0500 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 563165B797 for ; Thu, 20 Jan 2005 16:06:54 +0200 (EET) Received: from unknown[10.128.128.79]:58629 (EHLO fsintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.41.150 Release) with SMTP; Thu, 20 Jan 2005 14:06:52 -0000 Received: from [10.128.130.142] (unknown [10.128.130.142]) by fsintra.f-secure.com (Postfix) with ESMTP id 734715BD22 for ; Thu, 20 Jan 2005 16:06:52 +0200 (EET) Message-ID: <41EFBAB3.4060509@f-secure.com> Date: Thu, 20 Jan 2005 16:05:39 +0200 From: Sami Tikka Organization: F-Secure Corporation User-Agent: Mozilla Thunderbird 1.0 (X11/20050103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dazuko-devel@nongnu.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Dazuko-devel] Symlink reporting X-BeenThere: dazuko-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dazuko-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2005 14:27:35 -0000 Hi! It seems that dazuko 2.0.5-pre5 reports access to symlinks as access to the real file on both Linux 2.4 and 2.6. (I have not tested other platforms.) At least this is the case if both symlink and the real file are in the included directory. Our application (file integrity checker) needs to know both the symlink and the real file in case the file is accessed thru a symlink. (It needs to check that the symlink points to the correct file and that the file contents match the checksum.) I would propose that dazuko would always report the symlink access to the daemon. The daemon can see that the file is a symlink and readlink() to find out the real file. On Linux 2.6 I guess the way to go is to set up an inode_follow_link callback and report the symlink access from there. Unfortunately, when the inode_permission callback is called, there is no way to know if inode_follow_link was called previously. This means that on Linux 2.6 the dazuko driver would report file accesses thru symlink twice: first the access to the symlink and then the access to the real file. We already have an implementation of this. Should I post the patch or does someone feel there is another, better way to implement this? -- Sami Tikka tel: +358 9 2520 5115 Senior Software Engineer fax: +358 9 2520 5013 F-Secure Corporation http://www.F-Secure.com/ Be Sure. From MAILER-DAEMON Thu Jan 20 10:02:21 2005 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1CrdpE-0004oU-TN for mharc-dazuko-devel@gnu.org; Thu, 20 Jan 2005 10:02:21 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CrdpC-0004mw-Oe for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 10:02:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CrdpB-0004m7-W6 for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 10:02:18 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CrdoQ-00043H-BH for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 10:01:30 -0500 Received: from [193.110.109.20] (helo=fsmail-out.f-secure.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CrdLU-0003TE-LN for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 09:31:36 -0500 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 1DCE65B8EA for ; Thu, 20 Jan 2005 16:31:36 +0200 (EET) Received: from unknown[10.128.128.79]:59368 (EHLO fsintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.41.150 Release) with SMTP; Thu, 20 Jan 2005 14:31:34 -0000 Received: from [10.128.130.142] (unknown [10.128.130.142]) by fsintra.f-secure.com (Postfix) with ESMTP id 151EB5BD22 for ; Thu, 20 Jan 2005 16:31:34 +0200 (EET) Message-ID: <41EFC07D.8050106@f-secure.com> Date: Thu, 20 Jan 2005 16:30:21 +0200 From: Sami Tikka Organization: F-Secure Corporation User-Agent: Mozilla Thunderbird 1.0 (X11/20050103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dazuko-devel@nongnu.org Subject: Re: [Dazuko-devel] Symlink reporting References: <41EFBAB3.4060509@f-secure.com> In-Reply-To: <41EFBAB3.4060509@f-secure.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: dazuko-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dazuko-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2005 15:02:19 -0000 Sami Tikka wrote: > On Linux 2.6 I guess the way to go is to set up an inode_follow_link > callback and report the symlink access from there. Unfortunately, when > the inode_permission callback is called, there is no way to know if > inode_follow_link was called previously. This means that on Linux 2.6 > the dazuko driver would report file accesses thru symlink twice: first > the access to the symlink and then the access to the real file. To correct myself: We solved this double-reporting problem so that we introduced a new event type to dazuko: LINK. When the inode_follow_link is called, it is reported to daemon as a LINK type event. When inode_permission is called, it is reported as OPEN or EXEC as usual. Any opinions or better ideas? -- Sami Tikka tel: +358 9 2520 5115 Senior Software Engineer fax: +358 9 2520 5013 F-Secure Corporation http://www.F-Secure.com/ Be Sure. From MAILER-DAEMON Thu Jan 20 10:15:52 2005 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Cre2K-0003dt-LE for mharc-dazuko-devel@gnu.org; Thu, 20 Jan 2005 10:15:52 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cre2I-0003bl-BX for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 10:15:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cre2F-0003Xp-HC for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 10:15:48 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cre2E-0003X3-M7 for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 10:15:46 -0500 Received: from [217.11.63.31] (helo=orbb.hbedv.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Crdph-000817-Uk for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 10:02:50 -0500 Received: from localhost (unknown [127.0.0.1]) by orbb.hbedv.com (H+BEDV Postfix [Corporate]) with ESMTP id A15ED8BBD8; Thu, 20 Jan 2005 16:02:34 +0100 (CET) Received: from orbb.hbedv.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.2-5) id 30414-26F14604; Thu, 20 Jan 2005 16:02:34 +0100 Received: from greent.rd.hbedv.com (p5085DE03.dip0.t-ipconnect.de [80.133.222.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by orbb.hbedv.com (H+BEDV Postfix [Corporate]) with ESMTP id 5040A8BBD8; Thu, 20 Jan 2005 16:02:34 +0100 (CET) Received: from localhost (unknown [127.0.0.1]) by greent.rd.hbedv.com (H+BEDV Postfix [R&D]) with ESMTP id C330D7B4FC; Thu, 20 Jan 2005 15:02:45 +0000 (UTC) Received: from greent.rd.hbedv.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.2-5) id 06538-7EB677FE; Thu, 20 Jan 2005 16:02:45 +0100 Received: from [10.40.20.210] (jogness.unix.rd.hbedv.com [10.40.20.210]) by greent.rd.hbedv.com (H+BEDV Postfix [R&D]) with ESMTP id 2CA097B4FC; Thu, 20 Jan 2005 16:02:45 +0100 (CET) Message-ID: <41EFC80F.4090802@antivir.de> Date: Thu, 20 Jan 2005 16:02:39 +0100 From: John Ogness User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sami Tikka Subject: Re: [Dazuko-devel] Symlink reporting References: <41EFBAB3.4060509@f-secure.com> In-Reply-To: <41EFBAB3.4060509@f-secure.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-5; AVE: 6.29.0.8; VDF: 6.29.0.73; host: mail.hbedv.net) X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-5; AVE: 6.29.0.8; VDF: 6.29.0.73; host: smtp-relay.mail.antivir.de) Cc: dazuko-devel@nongnu.org X-BeenThere: dazuko-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jogness@antivir.de List-Id: dazuko-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2005 15:15:51 -0000 Sami Tikka wrote: > I would propose that dazuko would always report the symlink access to > the daemon. The daemon can see that the file is a symlink and readlink() > to find out the real file. Hi, Dazuko currently gets the accessed filename. If the file is a link it _also_ gets the real filename. These filenames are stored in a linked list called "aliases". If any of the aliases are included in the IncludePath, the file access is reported using that name. If both names are in the IncludePath, the real filename will be displayed. This is because new names are added to the front of the alias-list and the first matched name is returned. I agree that Dazuko should return the link and not the real name. This can be very easily fixed by adding new names to the end of the alias-list instead of to the beginning. > On Linux 2.6 I guess the way to go is to set up an inode_follow_link > callback and report the symlink access from there. Unfortunately, when > the inode_permission callback is called, there is no way to know if > inode_follow_link was called previously. This means that on Linux 2.6 > the dazuko driver would report file accesses thru symlink twice: first > the access to the symlink and then the access to the real file. As I mentioned before, this code is already implemented in Dazuko (for example, look at the xp_fill_file_struct() function in dazuko_linux.c). As long as registered applications are doing the readlink() calls, there will be no second event generated. > We already have an implementation of this. Should I post the patch or > does someone feel there is another, better way to implement this? I believe there is very little that must be changed (just reverse the order that the alias-list is built). But I would still be interested in seeing your patch. There may be some cool tricks there that I would like to use. ;) John Ogness -- Dazuko Maintainer From MAILER-DAEMON Thu Jan 20 10:34:22 2005 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1CreGT-0003rY-Kq for mharc-dazuko-devel@gnu.org; Thu, 20 Jan 2005 10:30:30 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CreGH-0003n4-5d for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 10:30:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CreGA-0003hW-OJ for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 10:30:11 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CreGA-0003ga-88 for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 10:30:10 -0500 Received: from [217.11.63.31] (helo=orbb.hbedv.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Cre1M-0000zd-5v for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 10:14:52 -0500 Received: from localhost (unknown [127.0.0.1]) by orbb.hbedv.com (H+BEDV Postfix [Corporate]) with ESMTP id 13E258BBD8; Thu, 20 Jan 2005 16:14:37 +0100 (CET) Received: from orbb.hbedv.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.2-5) id 30589-7C0BFAD9; Thu, 20 Jan 2005 16:14:37 +0100 Received: from greent.rd.hbedv.com (p5085DE03.dip0.t-ipconnect.de [80.133.222.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by orbb.hbedv.com (H+BEDV Postfix [Corporate]) with ESMTP id D8E7C8BBD8; Thu, 20 Jan 2005 16:14:36 +0100 (CET) Received: from localhost (unknown [127.0.0.1]) by greent.rd.hbedv.com (H+BEDV Postfix [R&D]) with ESMTP id C96657B4FE; Thu, 20 Jan 2005 15:14:48 +0000 (UTC) Received: from greent.rd.hbedv.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.2-5) id 10060-6677FAC0; Thu, 20 Jan 2005 16:14:48 +0100 Received: from [10.40.20.210] (jogness.unix.rd.hbedv.com [10.40.20.210]) by greent.rd.hbedv.com (H+BEDV Postfix [R&D]) with ESMTP id 330647B4FC; Thu, 20 Jan 2005 16:14:48 +0100 (CET) Message-ID: <41EFCAE2.2010006@antivir.de> Date: Thu, 20 Jan 2005 16:14:42 +0100 From: John Ogness User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sami Tikka Subject: Re: [Dazuko-devel] Symlink reporting References: <41EFBAB3.4060509@f-secure.com> <41EFC07D.8050106@f-secure.com> In-Reply-To: <41EFC07D.8050106@f-secure.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-5; AVE: 6.29.0.8; VDF: 6.29.0.73; host: mail.hbedv.net) X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-5; AVE: 6.29.0.8; VDF: 6.29.0.73; host: smtp-relay.mail.antivir.de) Cc: dazuko-devel@nongnu.org X-BeenThere: dazuko-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jogness@antivir.de List-Id: dazuko-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2005 15:30:24 -0000 Sami Tikka wrote: > To correct myself: We solved this double-reporting problem so that we > introduced a new event type to dazuko: LINK. When the inode_follow_link > is called, it is reported to daemon as a LINK type event. When > inode_permission is called, it is reported as OPEN or EXEC as usual. Hi, I am not sure that adding a READLINK would solve your recursive-entry problem. READLINK would probably come in addition to OPEN and not as a replacement. When "trusted applications" are supported (see http://www.dazuko.org/files/dazuko_mold2005_presentation.pdf) you shouldn't have this problem anymore. If we introduce new event types, it needs to be because applications are really interested in these events and not as a work-around for some desired functionality. John Ogness -- Dazuko Maintainer From MAILER-DAEMON Thu Jan 20 16:01:43 2005 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1CrjQv-00080p-Ki for mharc-dazuko-devel@gnu.org; Thu, 20 Jan 2005 16:01:38 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CrjNV-0007NX-Lp for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 15:58:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CrjNH-0007Ib-IO for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 15:57:52 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CrjNG-0007AG-Gb for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 15:57:50 -0500 Received: from [64.41.120.53] (helo=lva099.siteprotect.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Criun-0002UW-4f for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 15:28:25 -0500 Received: from epsilon.fn.ogness.net (pD9E5C807.dip.t-dialin.net [217.229.200.7]) by lva099.siteprotect.com (8.11.6/8.11.6) with ESMTP id j0KKSK524460; Thu, 20 Jan 2005 14:28:21 -0600 Received: from [192.168.0.10] (johno.fn.ogness.net [192.168.0.10]) by epsilon.fn.ogness.net (8.12.8p1/8.12.8) with ESMTP id j0KKRlqT026025; Thu, 20 Jan 2005 21:27:47 +0100 (CET) (envelope-from jogness@antivir.de) Message-ID: <41F0145F.4010007@antivir.de> Date: Thu, 20 Jan 2005 21:28:15 +0100 From: John Ogness User-Agent: Mozilla Thunderbird 0.9 (X11/20041114) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sami Tikka Subject: Re: [Dazuko-devel] Symlink reporting References: <41EFBAB3.4060509@f-secure.com> <41EFC80F.4090802@antivir.de> In-Reply-To: <41EFC80F.4090802@antivir.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dazuko-devel@nongnu.org X-BeenThere: dazuko-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jogness@antivir.de List-Id: dazuko-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2005 21:01:34 -0000 John Ogness wrote: > I agree that Dazuko should return the link and not the real name. This > can be very easily fixed by adding new names to the end of the > alias-list instead of to the beginning. I have implemented this in CVS for Linux 2.2/2.4 and FreeBSD 4/5. These changes won't make the 2.0.5 release, but you can check it out in CVS. $ env CVS_RSH="ssh" cvs -z3 \ -d:ext:anoncvs@subversions.gnu.org:/cvsroot/dazuko \ co dazuko For Linux 2.6 this would be quite a tricky challenge. inode_permission() does not provide the dentry of the link, even if a link is accessed. Dazuko currently has no way of knowing that a link was accessed under Linux 2.6. >> On Linux 2.6 I guess the way to go is to set up an inode_follow_link >> callback and report the symlink access from there. Unfortunately, when >> the inode_permission callback is called, there is no way to know if >> inode_follow_link was called previously. This means that on Linux 2.6 >> the dazuko driver would report file accesses thru symlink twice: first >> the access to the symlink and then the access to the real file. As you mentioned, I could also hook inode_follow_link(). I don't think we would want to generate an event from this, but Dazuko could be able to cache the link (along with the dereferenced dentry and task struct) so that when an inode_permission() call comes (and it is the same task struct and dentry) then I could assume it is the same call and include the link-dentry to the alias list. Does this sound ugly? ...yes. With the upcoming DazukoFS this will be much more elegant and reliable. The question is: should I spend development time trying to get these features to work with LSM or should I spend my time working on DazukoFS? Personally I would like to move away from LSM as soon as possible. Can we survive with LSM in its current form for another 3-6 months? John Ogness -- Dazuko Maintainer From MAILER-DAEMON Thu Jan 20 18:04:20 2005 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1CrlLg-00083P-Hy for mharc-dazuko-devel@gnu.org; Thu, 20 Jan 2005 18:04:20 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CrlLe-000836-Dy for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 18:04:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CrlJf-0007YE-8l for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 18:02:23 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CrlJc-0007TY-3p for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 18:02:12 -0500 Received: from [64.41.120.53] (helo=lva099.siteprotect.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CrkuH-0005WB-3m for dazuko-devel@nongnu.org; Thu, 20 Jan 2005 17:36:01 -0500 Received: from epsilon.fn.ogness.net (pD9E5C807.dip.t-dialin.net [217.229.200.7]) by lva099.siteprotect.com (8.11.6/8.11.6) with ESMTP id j0KMZww02800 for ; Thu, 20 Jan 2005 16:35:59 -0600 Received: from [192.168.0.10] (johno.fn.ogness.net [192.168.0.10]) by epsilon.fn.ogness.net (8.12.8p1/8.12.8) with ESMTP id j0KMZNqT026317 for ; Thu, 20 Jan 2005 23:35:24 +0100 (CET) (envelope-from jogness@antivir.de) Message-ID: <41F03249.5080500@antivir.de> Date: Thu, 20 Jan 2005 23:35:53 +0100 From: John Ogness User-Agent: Mozilla Thunderbird 0.9 (X11/20041114) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dazuko-devel@nongnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Dazuko-devel] Dazuko on FreeBSD (no more open-file-list) X-BeenThere: dazuko-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jogness@antivir.de List-Id: dazuko-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2005 23:04:18 -0000 Hi, I realized a couple days ago that the FreeBSD extension from Dazuko implements a work-around that was designed for Linux. The open-file lists have been causing lots of problems. Normally this list is not needed, but under Linux the necessary structures to do file_descriptor->file_name lookups are hidden from kernel modules. This is why Dazuko must track the file_names/file_descriptors as they are opened. However, FreeBSD does not hide it's code from modules. So under FreeBSD, closing file_descriptors should be no problem to look up the corresponding file_names. Well, I implemented this under FreeBSD 4 and it works beautifully (available in CVS). Right now it is only being used for the sys_close call. I will include this support to dup and dup2 shortly. Then I can copy it over to FreeBSD 5. This is great news because it means no more memory leaks or unreliability with ON_CLOSE events (under FreeBSD). Linux could also do this if people were willing to compile Dazuko into the kernel (and not as a kernel module). I may make this an option since ON_CLOSE is a very important event and the memory leaks it causes are unbearable. This implementation also means that there is no way to track writes (because I will eliminate the open-file-list). This means that ON_CLOSE_MODIFIED events will never be generated. I personally do not have a problem with this because the ON_CLOSE_MODIFIED events generate an enormous overhead for something that a userspace application can do itself easily (and much more effeciently). John Ogness -- Dazuko Maintainer From MAILER-DAEMON Fri Jan 21 10:14:51 2005 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Cs0Us-0007R0-DB for mharc-dazuko-devel@gnu.org; Fri, 21 Jan 2005 10:14:50 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cs0Up-0007OJ-4C for dazuko-devel@nongnu.org; Fri, 21 Jan 2005 10:14:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cs0Uj-0007L0-Ah for dazuko-devel@nongnu.org; Fri, 21 Jan 2005 10:14:43 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cs0Uj-0007JD-6D for dazuko-devel@nongnu.org; Fri, 21 Jan 2005 10:14:41 -0500 Received: from [193.110.109.20] (helo=fsmail-out.f-secure.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cs0C7-00023C-Q5 for dazuko-devel@nongnu.org; Fri, 21 Jan 2005 09:55:28 -0500 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id D22235B8A1; Fri, 21 Jan 2005 16:55:25 +0200 (EET) Received: from unknown[10.128.128.79]:44994 (EHLO fsintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.41.150 Release) with SMTP; Fri, 21 Jan 2005 14:55:23 -0000 Received: from [10.128.130.142] (unknown [10.128.130.142]) by fsintra.f-secure.com (Postfix) with ESMTP id D410A5BD22; Fri, 21 Jan 2005 16:55:23 +0200 (EET) Message-ID: <41F11790.1010705@f-secure.com> Date: Fri, 21 Jan 2005 16:54:08 +0200 From: Sami Tikka Organization: F-Secure Corporation User-Agent: Mozilla Thunderbird 1.0 (X11/20050103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jogness@antivir.de Subject: Re: [Dazuko-devel] Symlink reporting References: <41EFBAB3.4060509@f-secure.com> <41EFC07D.8050106@f-secure.com> <41EFCAE2.2010006@antivir.de> In-Reply-To: <41EFCAE2.2010006@antivir.de> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dazuko-devel@nongnu.org X-BeenThere: dazuko-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dazuko-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2005 15:14:48 -0000 John Ogness wrote: > Sami Tikka wrote: > >> To correct myself: We solved this double-reporting problem so that we >> introduced a new event type to dazuko: LINK. When the >> inode_follow_link is called, it is reported to daemon as a LINK type >> event. When inode_permission is called, it is reported as OPEN or EXEC >> as usual. > > > Hi, > > I am not sure that adding a READLINK would solve your recursive-entry > problem. READLINK would probably come in addition to OPEN and not as a > replacement. > > When "trusted applications" are supported (see > http://www.dazuko.org/files/dazuko_mold2005_presentation.pdf) you > shouldn't have this problem anymore. If we introduce new event types, it > needs to be because applications are really interested in these events > and not as a work-around for some desired functionality. Actually, I was not talking about the recursive-entry problem here. I was referring to our symlink-handling implementation. The first version of our symlink-patch caused two ON_CLOSE events to be sent from driver to daemon, one where the file was the symlink and one where the file was the real file. Later we modified our symlink-patch so that symlink access was reported as an ON_LINK event and the real file reported as an ON_OPEN event. Anyway, I will send you the patch. Code speaks clearer that words. Or at least my words... -- Sami Tikka tel: +358 9 2520 5115 Senior Software Engineer fax: +358 9 2520 5013 F-Secure Corporation http://www.F-Secure.com/ Be Sure. From MAILER-DAEMON Wed Jan 26 16:57:43 2005 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1CtvAV-0005c1-0w for mharc-dazuko-devel@gnu.org; Wed, 26 Jan 2005 16:57:43 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CtvAR-0005ZM-PH for dazuko-devel@nongnu.org; Wed, 26 Jan 2005 16:57:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CtvAO-0005XE-S5 for dazuko-devel@nongnu.org; Wed, 26 Jan 2005 16:57:37 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CtvAO-0005W9-CG for dazuko-devel@nongnu.org; Wed, 26 Jan 2005 16:57:36 -0500 Received: from [64.41.120.53] (helo=lva099.siteprotect.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CtusE-0004PM-FV for dazuko-devel@nongnu.org; Wed, 26 Jan 2005 16:38:50 -0500 Received: from epsilon.fn.ogness.net (pD954847E.dip.t-dialin.net [217.84.132.126]) by lva099.siteprotect.com (8.11.6/8.11.6) with ESMTP id j0QLckp28549 for ; Wed, 26 Jan 2005 15:38:47 -0600 Received: from [192.168.0.10] (johno.fn.ogness.net [192.168.0.10]) by epsilon.fn.ogness.net (8.12.8p1/8.12.8) with ESMTP id j0QLcKqT051708 for ; Wed, 26 Jan 2005 22:38:21 +0100 (CET) (envelope-from jogness@antivir.de) Message-ID: <41F80DE4.2030203@antivir.de> Date: Wed, 26 Jan 2005 22:38:44 +0100 From: John Ogness User-Agent: Mozilla Thunderbird 0.9 (X11/20041114) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dazuko-devel@nongnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Dazuko-devel] MAJOR CVS commit X-BeenThere: dazuko-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jogness@antivir.de List-Id: dazuko-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2005 21:57:40 -0000 Hi, I have just finished commiting some changes that I have been working on for a week now. These are some major changes that include major improvements. A little history: I originally received the source code to the Dazuko Project back in November 2001. Over the years I have worked to improve both the feature set and the design. From Dazuko 1.0 there are only 2 major items that still exist in the code today. - hooking the system call table - using a hash list of open files to determine file names "on close" The second item (with the hash list) has always been a big, inefficient problem with Dazuko. Since Dazuko has had other more important problems in the past, this problem has always been low-priority. Well, about a week ago I started taking this problem seriously and started digging in the kernel code to see what is going on. What did I discover? Dazuko doesn't need this hash list at all!!! It is no problem to lookup filenames (ie. grab dentry's) if you have a file descriptor! I have now ripped out the hash list and implemented this on all operating systems. It works beautifully! - ON_CLOSE events are now reliable and accurate - ON_CLOSE and ON_OPEN events are now much faster - much less memory allocation and no more memory leaks At the moment this means that ON_CLOSE_MODIFIED events will never be generated, but I already have a plan how to bring them back (without any real overhead). These changes are only available in CVS. They will be posted on the website as a 2.1.0-pre-release (in a week and a half). John Ogness -- Dazuko Maintainer From MAILER-DAEMON Fri Jan 28 04:32:02 2005 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1CuSTw-0000IG-QN for mharc-dazuko-devel@gnu.org; Fri, 28 Jan 2005 04:32:01 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CuSTt-0000Hb-Tw for dazuko-devel@nongnu.org; Fri, 28 Jan 2005 04:31:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CuSTs-0000HL-Mr for dazuko-devel@nongnu.org; Fri, 28 Jan 2005 04:31:57 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CuSTY-0008GR-Og for dazuko-devel@nongnu.org; Fri, 28 Jan 2005 04:31:36 -0500 Received: from [193.110.109.20] (helo=fsmail-out.f-secure.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CuRz0-0001gN-Be for dazuko-devel@nongnu.org; Fri, 28 Jan 2005 04:00:02 -0500 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 603665B865; Fri, 28 Jan 2005 11:00:00 +0200 (EET) Received: from fsintra.f-secure.com[10.128.128.79]:35564 (EHLO fsintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.41.150 Release) with SMTP; Fri, 28 Jan 2005 08:59:58 -0000 Received: from [10.128.130.142] (unknown [10.128.130.142]) by fsintra.f-secure.com (Postfix) with ESMTP id EBBB25BD22; Fri, 28 Jan 2005 10:59:58 +0200 (EET) Message-ID: <41F9FEA6.4060202@f-secure.com> Date: Fri, 28 Jan 2005 10:58:14 +0200 From: Sami Tikka Organization: F-Secure Corporation User-Agent: Mozilla Thunderbird 1.0 (X11/20050103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jogness@antivir.de, dazuko-devel@nongnu.org Subject: Re: [Dazuko-devel] Symlink reporting References: <41EFBAB3.4060509@f-secure.com> <41EFC07D.8050106@f-secure.com> <41EFCAE2.2010006@antivir.de> <41F11790.1010705@f-secure.com> In-Reply-To: <41F11790.1010705@f-secure.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------080800020801070206060704" Cc: X-BeenThere: dazuko-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dazuko-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2005 09:31:58 -0000 This is a multi-part message in MIME format. --------------080800020801070206060704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sami Tikka wrote: > Later we modified our symlink-patch so that symlink access was reported > as an ON_LINK event and the real file reported as an ON_OPEN event. > > Anyway, I will send you the patch. Code speaks clearer that words. Or at > least my words... Here she comes. This patch was made against dazuko 2.0.4-pre2. I tried to apply the patches against your latest dazuko release but that did not produce a good version. I define a good version as a version that sends the name of the symlink to the daemon if a symlink was accessed. I'll try to find out the problem but I thought I'd send you this patch just so you can see what I'm getting at. -- Sami Tikka tel: +358 9 2520 5115 Senior Software Engineer fax: +358 9 2520 5013 F-Secure Corporation http://www.F-Secure.com/ Be Sure. --------------080800020801070206060704 Content-Type: text/plain; name="dazuko-symlink-patch-20" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dazuko-symlink-patch-20" --- orig/dazuko_linux26.c +++ mod/dazuko_linux26.c @@ -52,6 +52,13 @@ int dazuko_register_security(const char *name, struct security_operations *ops); int dazuko_unregister_security(const char *name, struct security_operations *ops); + +enum { + DPUT_UNSET=0, + DPUT_FREE=1, + DPUT_DONTFREE=2 +}; + static struct file_operations fops = { .owner = THIS_MODULE, .read = linux_dazuko_device_read, @@ -342,7 +349,7 @@ if (xfs->inode == NULL) return 0; - if (!S_ISREG(xfs->inode->i_mode)) + if (!S_ISREG(xfs->inode->i_mode) && !S_ISLNK(xfs->inode->i_mode)) return 0; if (xfs->nd == NULL || xfs->free_full_filename) @@ -375,12 +382,12 @@ } /* make sure we don't already have a dentry */ - if (!xfs->dput_dentry) + if (xfs->dput_dentry == DPUT_UNSET) { xfs->dentry = dget(xfs->nd->dentry); /* the dentry will need to be put back */ - xfs->dput_dentry = 1; + xfs->dput_dentry = DPUT_FREE; } rootmnt = mntget(orig_rootmnt); @@ -460,10 +467,10 @@ dfs->extra_data->free_page_buffer = 0; } - if (dfs->extra_data->dput_dentry) + if (dfs->extra_data->dput_dentry == DPUT_FREE) { dput(dfs->extra_data->dentry); - dfs->extra_data->dput_dentry = 0; + dfs->extra_data->dput_dentry = DPUT_UNSET; } if (dfs->extra_data->mntput_vfsmount) @@ -741,6 +748,7 @@ { dazuko_bzero(dfs->extra_data, sizeof(struct xp_file_struct)); + dfs->extra_data->dput_dentry = DPUT_UNSET; dfs->extra_data->nd = nd; dfs->extra_data->inode = inode; @@ -762,6 +770,67 @@ return 0; } +int dazuko_inode_follow_link(struct dentry *dentry, struct nameidata *nd) +{ + struct dazuko_file_struct *dfs = NULL; + int error = 0; + int check_error = 0; + struct event_properties event_p; + struct xp_daemon_id xp_id; + + xp_id.pid = current->pid; + xp_id.ppid = current->parent ? current->parent->pid : 0; + xp_id.file = NULL; + + dazuko_bzero(&event_p, sizeof(event_p)); + + event_p.flags = 0; + event_p.set_flags = 0; + + check_error = dazuko_sys_check(DAZUKO_ON_LINK, 1, &xp_id); + + if (!check_error) + { + event_p.mode = dentry->d_inode->i_mode; + event_p.set_mode = 1; + event_p.pid = current->pid; + event_p.set_pid = 1; + event_p.uid = current->uid; + event_p.set_uid = 1; + + dfs = (struct dazuko_file_struct *)xp_malloc(sizeof(struct dazuko_file_struct)); + if (dfs != NULL) + { + dazuko_bzero(dfs, sizeof(struct dazuko_file_struct)); + + dfs->extra_data = (struct xp_file_struct *)xp_malloc(sizeof(struct xp_file_struct)); + if (dfs->extra_data != NULL) + { + dazuko_bzero(dfs->extra_data, sizeof(struct xp_file_struct)); + + dfs->extra_data->dentry = dentry; + dfs->extra_data->dput_dentry = DPUT_DONTFREE; + dfs->extra_data->nd = nd; + dfs->extra_data->inode = dentry->d_inode; + + error = dazuko_sys_pre(DAZUKO_ON_LINK, dfs, &event_p); + } + else + { + xp_free(dfs); + dfs = NULL; + } + + dazuko_file_struct_cleanup(&dfs); + } + } + + if (error) + return XP_ERROR_PERMISSION; + + return 0; +} + inline int xp_sys_hook() { struct security_operations dummy_ops; @@ -816,6 +885,7 @@ memcpy(&dazuko_security_ops, &dazuko_security_default_ops, sizeof(dazuko_security_ops)); dazuko_security_ops.inode_permission = dazuko_inode_permission; + dazuko_security_ops.inode_follow_link = dazuko_inode_follow_link; if (!got_dummy || register_security(&dazuko_register_security_ops) != 0) { --- orig/dazuko_xp.c +++ mod/dazuko_xp.c @@ -46,6 +46,7 @@ #define SCAN_ON_CLOSE (access_mask & DAZUKO_ON_CLOSE) #define SCAN_ON_EXEC (access_mask & DAZUKO_ON_EXEC) #define SCAN_ON_CLOSE_MODIFIED (access_mask & DAZUKO_ON_CLOSE_MODIFIED) +#define SCAN_ON_LINK (access_mask & DAZUKO_ON_LINK) struct path { --- orig/dazukoio.h +++ mod/dazukoio.h @@ -42,6 +42,7 @@ #define DAZUKO_ON_CLOSE_MODIFIED 8 #define DAZUKO_ON_UNLINK 16 #define DAZUKO_ON_RMDIR 32 +#define DAZUKO_ON_LINK 64 struct dazuko_access { --- orig/example_c/example.c +++ mod/example_c/example.c @@ -97,6 +97,9 @@ case DAZUKO_ON_RMDIR: printf("RMDIR "); break; + case DAZUKO_ON_LINK: + printf("LINK "); + break; default: printf("???? event:%d ", acc->event); break; @@ -166,7 +169,7 @@ signal(SIGINT, sigterm); /* set access mask */ - if (dazukoSetAccessMask(DAZUKO_ON_OPEN | DAZUKO_ON_CLOSE | DAZUKO_ON_CLOSE_MODIFIED | DAZUKO_ON_EXEC | DAZUKO_ON_UNLINK | DAZUKO_ON_RMDIR) != 0) + if (dazukoSetAccessMask(DAZUKO_ON_OPEN | DAZUKO_ON_CLOSE | DAZUKO_ON_CLOSE_MODIFIED | DAZUKO_ON_EXEC | DAZUKO_ON_UNLINK | DAZUKO_ON_RMDIR | DAZUKO_ON_LINK) != 0) { printf("error: failed to set access mask\n"); dazukoUnregister(); --------------080800020801070206060704 Content-Type: text/plain; name="dazuko-symlink-patch-21" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dazuko-symlink-patch-21" --- orig/dazuko_linux.c +++ mod/dazuko_linux.c @@ -379,7 +379,7 @@ dazuko_bzero(&(xfs->nd), sizeof(struct nameidata)); /* initialize nameidata structure for finding file data */ - if (!path_init(xfs->filename, LOOKUP_FOLLOW | LOOKUP_POSITIVE, &(xfs->nd))) + if (!path_init(xfs->filename, LOOKUP_POSITIVE, &(xfs->nd))) return 0; if (!xfs->path_release_nd) @@ -563,7 +563,8 @@ #endif { /* make sure the file is readable */ - if (S_ISREG(dfs->extra_data->dentry->d_inode->i_mode)) + if (S_ISREG(dfs->extra_data->dentry->d_inode->i_mode) || + S_ISLNK(dfs->extra_data->dentry->d_inode->i_mode)) { /* make sure we can get the full path */ if (dazuko_get_full_filename(dfs->extra_data)) --------------080800020801070206060704-- From MAILER-DAEMON Fri Jan 28 14:01:27 2005 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1CubN1-0004nT-Fp for mharc-dazuko-devel@gnu.org; Fri, 28 Jan 2005 14:01:27 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CubMz-0004nI-OT for dazuko-devel@nongnu.org; Fri, 28 Jan 2005 14:01:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CubMz-0004n6-4e for dazuko-devel@nongnu.org; Fri, 28 Jan 2005 14:01:25 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CubMj-0004Km-TO for dazuko-devel@nongnu.org; Fri, 28 Jan 2005 14:01:09 -0500 Received: from [193.110.109.20] (helo=fsmail-out.f-secure.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CuagO-00035B-OR for dazuko-devel@nongnu.org; Fri, 28 Jan 2005 13:17:25 -0500 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 11FB05BB17; Fri, 28 Jan 2005 20:17:24 +0200 (EET) Received: from fsintra.f-secure.com[10.128.128.79]:53191 (EHLO fsintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.41.150 Release) with SMTP; Fri, 28 Jan 2005 18:17:22 -0000 Received: from fsfimail3.FI.F-Secure.com (fsfimail3.fi.f-secure.com [10.128.128.21]) by fsintra.f-secure.com (Postfix) with ESMTP id 8B9E85BD22; Fri, 28 Jan 2005 20:17:22 +0200 (EET) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dazuko-devel] Symlink reporting Date: Fri, 28 Jan 2005 20:17:22 +0200 Message-ID: <83879A37F8F8E8439B850BD8F9364A660802D0@fsfimail3.fi.f-secure.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dazuko-devel] Symlink reporting Thread-Index: AcUFGnaDYOg9GnNOR6yF5o30xWZ9FgASw/Pw From: "Tikka, Sami" To: , Cc: X-BeenThere: dazuko-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dazuko-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2005 19:01:26 -0000 >-----Original Message----- >From: dazuko-devel-bounces+sami.tikka=3Df-secure.com@nongnu.org=20 >[mailto:dazuko-devel-bounces+sami.tikka=3Df-secure.com@nongnu.org >] On Behalf Of Tikka, Sami >Sent: Friday, January 28, 2005 10:58 AM >To: jogness@antivir.de; dazuko-devel@nongnu.org >Subject: Re: [Dazuko-devel] Symlink reporting > >I tried to apply the patches against your latest dazuko=20 >release but that=20 >did not produce a good version. I define a good version as a version=20 >that sends the name of the symlink to the daemon if a symlink was=20 >accessed. I'll try to find out the problem but I thought I'd send you=20 >this patch just so you can see what I'm getting at. Yes, I found the problem and I just re-read the emails and realized that = you had already fixed the symlink behaviour in the CVS, thanks!=20 Anyway, we have the symlink reporting for Linux 2.6, as you can see in = the patches. And because it is not possible to know in LSM inode_permission callback if LSM follow_symlink callback has already been called, we = report both. We just use a different event (ON_LINK) to report symlink access. = I can explain why we did that: We have 2 modules that listen to dazuko events: Integrity Checker and Anti-Virus. Integrity Checker is interested in both symlink and file = accesses because it has to verify that a) the symlink points to the right place = and b) the checksum of the file matches to what is stored to baseline. = Anti-Virus module just wants to scan the file. When user accesses a file via a symlin, on Linux 2.4 we have dazuko send = us ON_OPEN event with the name of the symlink. Intergrity Checker sees it = is a symlink, checks it points to the right place, readlinks the symlink and verifies checksum of the file. Anti-Virus scanner just scans the = reported name and does not care if it was a symlink or a file. On Linux 2.6 we have dazuko send us ON_LINK event with the name of the symlink. Integrity Checker checks that the link points to the right = place and nothing else. Anti-Virus scanner just ignores the ON_LINK events. Then = dazuko sends us ON_OPEN event with the name of the real file. Integrity Checker = sees this is a file, not a symlink and just verifies checksum of the file. Anti-Virus scanner simply scans the reported filename. If you do not like the concept of introducing ON_LINK events for Linux = 2.6, we could just make LSM follow_symlink callback send ON_OPEN events. Our Integrity Checker and Anti-Virus could live with it because we cache = virus scan results so it would not be a problem to have ON_OPEN reported = twice, once for the symlink and once for the real file. --=20 Sami Tikka tel. +358 9 2520 5115=20 senior software engineer fax. +358 9 2520 5014 mobile +358 40 7379388 F-Secure Corporation http://www.f-secure.com BE SURE