Re: Q on audit, audit-syscall

[Herbert Rosmanith <kernel@wildsau.enemy.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 <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