From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932086AbWDEVvZ (ORCPT ); Wed, 5 Apr 2006 17:51:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932087AbWDEVvZ (ORCPT ); Wed, 5 Apr 2006 17:51:25 -0400 Received: from wildsau.enemy.org ([193.170.194.34]:13195 "EHLO wildsau.enemy.org") by vger.kernel.org with ESMTP id S932086AbWDEVvY (ORCPT ); Wed, 5 Apr 2006 17:51:24 -0400 From: Herbert Rosmanith Message-Id: <200604052147.k35LlOpK010229@wildsau.enemy.org> Subject: Re: Q on audit, audit-syscall In-Reply-To: <200604052036.k35KaQXk021296@turing-police.cc.vt.edu> To: Valdis.Kletnieks@vt.edu Date: Wed, 5 Apr 2006 23:47:24 +0200 (MET DST) CC: Kyle Moffett , Robin Holt , linux-kernel@vger.kernel.org X-Mailer: ELM [version 2.4ME+ PL100 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > 'man auditd' and friends. This is providing after-the-fact reporting > of security-related events for audit and forensic analysis. We have *no* sure, I've already found audit, unfortunately, it wont compile on my system :-( else I'd already be busy analysing how it works. this is yet another time that using auto-tools results in more work than without. I get a failure in an automatically generated, 7000+ lines monster shell-script named "libtool". I wonder why "libtool" is generated by audit: # libtool - Provide generalized library-building support services. # Generated automatically by (GNU audit 1.1.5) (I thought "libtool" is part of the system - why does audit generate one itself?) anyway, the manpage describes how auditd/libaudit works - not how it has been implemented/how it communicates with the kernel. I want to know how it works "under the hood", not just how to use it. but I think I slowly get the idea (more on this below). > idea if it will fill your needs, because you have explained what you're > trying to *do* with ptrace. If you merely need a record that a syscall as I said, "ptrace" is not an option, so I'm not trying to do anything with it. > happened, this is what you want. If you want to apply a security restriction, > you want to look at SELinux or perhaps a custom LSM. If you have some ^^^^^^^^^^^^ the idea already crossed my mind. but I rather start bottom up: LSM depends on CONFIG_AUDIT* (this is correct, isn't it?), so I examine AUDIT first. if AUDIT doesnt support what I need, I continue with LSM. > other need, you need some other tool. > So what problem are you trying to solve by using ptrace()? I'm *not* using ptrace :-) Kyle suggested I use it, but I dont want to. > > (2) in linux/Documentation/devices.txt I've found an "audit device": > > 103 block Audit device > > 0 = /dev/audit Audit device > > "That is an old worn-out magic word" -- ADVENT.FOR > I think that's a leftover from before the audit subsystem was converted > to use netlink. ok. good, some clear words! so this obsolete entry should be removed or clearly flagged as "obsolete". see what I mean: linux/Documentation is not the place to go when you look for accurate docs! it has some potential to lead to confusion. this was not the first time that docs in linux/Documentation proofed outdated - but I realised only after I "crashed into the wall". > > (3) audit-1.1.5/lib is using "socket(PF_NETLINK,SOCK_RAW,NETLINK_AUDIT)" > > is this the way to communicate with the audit-system enabled by > > CONFIG_AUDIT/_AUDITSYSCALL? or is this something different. > > Well, this is how auditd talks to the netlink socket. ok. is this correct: I can communicate with the whole audit system via the netlink-socket and there is no other means (e.g. a syscall, a /proc interface, a block-device with major 103 ;-))) for it. good! this was the info I was looking for. > Whether it supports the functionality you need in a unpatched kernel depends on > what you're trying to do Thanks, I'll find out myself. The next step is playing with the audit-messages from to see if > (which you still haven't explained). how goes the joke ... "I can explain it to you, but then I'd have to shoot you":-) sorry :-)) no, really: it's (1) too easy (2) unpublished (3) the background is not related to the linux kernel at all (4) I dont want you to solve my "homework". but I understand ... someone asks "how does X work", then you usually ask "tell us why do you want to use X" in order to see if "X" is the correct method at all. but in this case, I have to find out myself if method "X" fits my needs. sorry. > > > otherwise it's impossible to help you. You want to trace and > > > intercept syscalls, no? > > > > > It implicitly doesn't make any sense to try to trace and intercept syscalls > > > from one process in more than one other. > > > > I'm pretty sure I can find a quote from the fortune program saying > > that "if something does not make sense for you, that doesnt mean that it wont > > make sense for someone else". In fact, it makes sense for me. > > Good. Please enlighten us what the proper system behavior is, if *two* processes > are ptrace()ing the same target process - and one specifies PTRACE_CONT and good point! this again proves that ptrace is not an option - as I noted in my first mail. [...] > LAuS was a long-ago predecessor of the current audit system. At the time > it was written, it was correct, but it no longer is. aha. good to know. thanks. regards, h.rosmanith