Messages in this thread | | | From | Herbert Rosmanith <> | Subject | Re: Q on audit, audit-syscall | Date | Wed, 5 Apr 2006 23:47:24 +0200 (MET DST) |
| |
> '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 <linux/audit.h> 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
- 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/
| |