Q on audit, audit-syscall

Q on audit, audit-syscall

[Herbert Rosmanith]

good afternoon,

I'm searching for a way to trace/intercept syscalls, both before and
after execution. "ptrace" is not an option (you probably know why).
I've found CONFIG_AUDIT and CONFIG_AUDITSYSCALL, which offer
"audit_syscall_entry" and "audit_syscall_exit", but I dont know
how to use this. Also, the comment in kernel/auditsc.c reads:
 * The method for actual interception of syscall entry and exit (not in
 * this file -- see entry.S) is based on a GPL'd patch written by
 * okir@suse.de and Copyright 2003 SuSE Linux AG.

So, am I looking in the wrong file?

I just cant see how this software communicates with user-space,
there is no "register_xxx" (or whatever) in the source-files.
Is it neccessary to write an additional module (like se-linux does)
which makes use of audit and exports its own functionality to
userspace?

So far, in the audit-1.1.5 deamon, I've only found a PF_NETLINK/NETLINK_AUDIT
socket. *Is* this it?

What's additionally confusing me is that linux/Documentation/devices.txt
says that "block 130 minor 0 = Audit device", yet, allthugh I'm running
with 2.6.16 + CONFIG_AUDIT & CONFIG_AUDITSYSCALL, there just is no
block dev 130 in /proc/devices. Is the entry in devices.txt wrong?

regards,
h.rosmanith

Re: Q on audit, audit-syscall

[Robin Holt]

On Wed, Apr 05, 2006 at 01:27:03PM +0200, Herbert Rosmanith wrote:
> 
> good afternoon,
> 
> I'm searching for a way to trace/intercept syscalls, both before and
> after execution. "ptrace" is not an option (you probably know why).

Does strace do what you are asking for?

Robin

Re: Q on audit, audit-syscall

[Herbert Rosmanith]

> On Wed, Apr 05, 2006 at 01:27:03PM +0200, Herbert Rosmanith wrote:
> > 
> > good afternoon,
> > 
> > I'm searching for a way to trace/intercept syscalls, both before and
> > after execution. "ptrace" is not an option (you probably know why).
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^

> Does strace do what you are asking for?

as I said, "ptrace" is not an option.

Re: Q on audit, audit-syscall

[Kyle Moffett]

On Apr 5, 2006, at 08:06:30, Herbert Rosmanith wrote:
>> On Wed, Apr 05, 2006 at 01:27:03PM +0200, Herbert Rosmanith wrote:
>>>
>>> good afternoon,
>>>
>>> I'm searching for a way to trace/intercept syscalls, both before  
>>> and after execution. "ptrace" is not an option (you probably know  
>>> why).
>>
>> Does strace do what you are asking for?
>
> as I said, "ptrace" is not an option.

Why not, exactly?  (No, we don't know why).  ptrace is _the_ Linux  
mechanism to trace and intercept syscalls.  There is no other way.

Cheers,
Kyle Moffett

Re: Q on audit, audit-syscall

[Herbert Rosmanith]

> On Apr 5, 2006, at 08:06:30, Herbert Rosmanith wrote:
> >> On Wed, Apr 05, 2006 at 01:27:03PM +0200, Herbert Rosmanith wrote:
> >>>
> >>> good afternoon,
> >>>
> >>> I'm searching for a way to trace/intercept syscalls, both before  
> >>> and after execution. "ptrace" is not an option (you probably know  
> >>> why).
> >>
> >> Does strace do what you are asking for?
> >
> > as I said, "ptrace" is not an option.
> 
> Why not, exactly?  (No, we don't know why).

according to the man-page:

RETURN VALUES
     EPERM   The specified process [...] is already being traced.

this makes it unusable for me.

>  ptrace is _the_ Linux  mechanism to trace and intercept syscalls.
>
> There is no other way.

"there is no other way": [1,2,3,4]

regards,
h.rosmanith

[1] http://www.uniforum.chi.il.us/slides/HardeningLinux/LAuS-Design.pdf
[2] http://www.usenix.org/publications/library/proceedings/als01/full_papers/edwards/edwards.pdf
[3] http://www.citi.umich.edu/u/provos/papers/systrace.pdf
[4] http://www.nsa.gov/selinux/papers/freenix01.pdf

Re: Q on audit, audit-syscall

[Kyle Moffett]

On Apr 5, 2006, at 09:50:17, Herbert Rosmanith wrote:
>> On Apr 5, 2006, at 08:06:30, Herbert Rosmanith wrote:
>>> as I said, "ptrace" is not an option.
>>
>> Why not, exactly?  (No, we don't know why).
>
> according to the man-page:
>
> RETURN VALUES
>      EPERM   The specified process [...] is already being traced.
>
> this makes it unusable for me.

Please stop being unclear and describe _exactly_ what you want to do;  
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.

>> ptrace is _the_ Linux  mechanism to trace and intercept syscalls.   
>> There is no other way.
> "there is no other way": [1,2,3,4]
>
> [1] http://www.uniforum.chi.il.us/slides/HardeningLinux/LAuS- 
> Design.pdf
> [2] http://www.usenix.org/publications/library/proceedings/als01/ 
> full_papers/edwards/edwards.pdf
> [3] http://www.citi.umich.edu/u/provos/papers/systrace.pdf
> [4] http://www.nsa.gov/selinux/papers/freenix01.pdf

It looks like you solved your own problem, then!  Feel free to use  
any one of those.  The only commonly-available mainline mechanism to  
_trace_ and _intercept_ syscalls is ptrace.  If you happen to be  
looking for how to implement extra process security checks, might I  
suggest looking at Linux Security Modules?  On the other hand, I  
think LSMs may never even see some requests if they fail access- 
restrictions before calling into the LSM.  I believe there's  
documentation on them in the linux/Documentation dir of your copies  
of the linux sources.

Cheers,
Kyle Moffett

Re: Q on audit, audit-syscall

[Herbert Rosmanith]

> On Apr 5, 2006, at 09:50:17, Herbert Rosmanith wrote:
> >> On Apr 5, 2006, at 08:06:30, Herbert Rosmanith wrote:
> >>> as I said, "ptrace" is not an option.
> >>
> >> Why not, exactly?  (No, we don't know why).
> >
> > according to the man-page:
> >
> > RETURN VALUES
> >      EPERM   The specified process [...] is already being traced.
> >
> > this makes it unusable for me.
> 
> Please stop being unclear and describe _exactly_ what you want to do;  
                                         ^^^^^^^^^

Check my initial email, you'll see that I've been pretty _clear_ and
I've _exactly_ described what I am looking for: for description of
interfaces and software.  I cannot find good (if any) documentation on
this (see below), neither via google, nor by examining the
kernel-sources.

You see, I am asking for documentation. I am not asking "please solve my
problem."

Or is the LKML the wrong place to ask this kind of question?

okay then:

(1) CONFIG_AUDIT and CONFIG_AUDITSYSCALL: how do I use that from
    userspace? is it possible at all (1.1) to use this from userspace or
    (1.2) is this a "kernel-only" infrastructure provided for other
    kernel-modules only (such as e.g. LSM?). is there a description
    of this interface and how and where to use it? I cannot find it.
    clear enough?

(2) in linux/Documentation/devices.txt I've found an "audit device":

        103 block       Audit device
                          0 = /dev/audit        Audit device

    which software implements this device? I see no block-device
    registration in linux/kernel/audit.c nor in linux/kernel/auditsc.c.
    Booting a kernel with CONFIG_AUDIT* enabled does not show this
    device in /proc/devices.

    so, what the deal with this block device? clear enough?


(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.
    (thanks to auto-tools, compilation of audit-1.1.5 fails, so unfortunately
    I could not watch it running until now. God, I hate automake!)

> 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.
  
> >> ptrace is _the_ Linux  mechanism to trace and intercept syscalls.   
> >> There is no other way.
> > "there is no other way": [1,2,3,4]
> >
> > [1] http://www.uniforum.chi.il.us/slides/HardeningLinux/LAuS- 
> > Design.pdf
> > [2] http://www.usenix.org/publications/library/proceedings/als01/ 
> > full_papers/edwards/edwards.pdf
> > [3] http://www.citi.umich.edu/u/provos/papers/systrace.pdf
> > [4] http://www.nsa.gov/selinux/papers/freenix01.pdf
> 
> It looks like you solved your own problem, then!

obviously not, because then I would not be asking question on LKML.
Of course I have read these papers before, but I am not 100% satisfied.

>  Feel free to use  any one of those.  The only commonly-available
> mainline mechanism to  _trace_ and _intercept_ syscalls is ptrace.  

with the limitation of ptrace, -EPERM -- see above.

> If you happen to be  looking for how to implement extra process
> security checks, might I suggest looking at Linux Security Modules?  On
> the other hand, I  think LSMs may never even see some requests if they
> fail access- restrictions before calling into the LSM.  I believe
> there's  documentation on them in the linux/Documentation dir of your
                                        ^^^^^^^^^^^^^^^^^^^

hm, yes, maybe, on the other hand:

/usr/src/linux/Documentation$ grep -i audit *
devices.txt:103 block   Audit device
devices.txt:              0 = /dev/audit        Audit device
/usr/src/linux/Documentation$ find -type d | grep -i audit
/usr/src/linux/Documentation$ 

that's not much. a textual search through linux/Documentation shows hits
in RCU/listRCU.txt mostly, which doesnt seem to deal with auditing. In my
experience, linux/Documentation is not a full documentation.
I wonder if IBM and SuSE/Novell are right when they write in~\ref{1}:

\begin{quote}
The vanilla 2.6 Linux kernel does not provide a mechanism to
trace syscalls in the desired way, nor does it contain the
capability to to track process and generate an audit trail.
\end{quote}

But on the other hand, we see kernel-options like CONFIG_AUDIT,
CONFIG_AUDITSYSCALL, CONFIG_SECURITY etc. etc. So, how can IBM & SuSE
argue this way? The attempt to review their statement is one
reason for my email to LKML.

> copies  of the linux sources.

regards,
h.rosmanith

[1] http://www.uniforum.chi.il.us/slides/HardeningLinux/LAuS-Design.pdf

Re: Q on audit, audit-syscall

[Robin Holt]

On Wed, Apr 05, 2006 at 10:04:55PM +0200, Herbert Rosmanith wrote:
> >  Feel free to use  any one of those.  The only commonly-available
> > mainline mechanism to  _trace_ and _intercept_ syscalls is ptrace.  
> 
> with the limitation of ptrace, -EPERM -- see above.

I guess I am dense, but what is already tracing this process?

Thanks,
Robin

Re: Q on audit, audit-syscall

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 3877 bytes --]

On Wed, 05 Apr 2006 22:04:55 +0200, Herbert Rosmanith said:

> (1) CONFIG_AUDIT and CONFIG_AUDITSYSCALL: how do I use that from
>     userspace? is it possible at all (1.1) to use this from userspace or
>     (1.2) is this a "kernel-only" infrastructure provided for other
>     kernel-modules only (such as e.g. LSM?). is there a description
>     of this interface and how and where to use it? I cannot find it.
>     clear enough?

'man auditd' and friends.  This is providing after-the-fact reporting
of security-related events for audit and forensic analysis.  We have *no*
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
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
other need, you need some other tool.

So what problem are you trying to solve by using ptrace()?

> (2) in linux/Documentation/devices.txt I've found an "audit device":
> 
>         103 block       Audit device
>                           0 = /dev/audit        Audit device
> 
>     which software implements this device? I see no block-device
>     registration in linux/kernel/audit.c nor in linux/kernel/auditsc.c.
>     Booting a kernel with CONFIG_AUDIT* enabled does not show this
>     device in /proc/devices.
> 
>     so, what the deal with this block device? clear enough?

"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.

> (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.  Whether it supports
the functionality you need in a unpatched kernel depends on what you're
trying to do (which you still haven't explained).

> > 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
the other PTRACE_SINGLESTEP (or other conflicting pairs of requests...)
Handling two PTRACE_{GET|POKE}* requests for the same data looks massively
racy as well, as there's no defined way to say what order to handle them.

But hey - if you're comfortable and get warm fuzzies about the idea that one
process could use PTRACE_POKEDATA to set the variable 'a_upper_lim' to 23, and
the other could use it to set a_upper_lim to -10, and then execution resumes
with no clear indication of which one actually gets used, that's OK by us...

(Or for more fun - what if one process sends a PTRACE_CONT before the other one
gets a shot at it to do the PTRACE_POKEDATA, at which point you're storing into
a already-running process (bonus points for knowing if the live value is in a
register or in memory at the time you get there with a non-stopped process ;)

> I wonder if IBM and SuSE/Novell are right when they write in~\ref{1}:
> 
> \begin{quote}
> The vanilla 2.6 Linux kernel does not provide a mechanism to
> trace syscalls in the desired way, nor does it contain the
> capability to to track process and generate an audit trail.
> \end{quote}

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.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Q on audit, audit-syscall

[Herbert Rosmanith]

 
> '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

Re: Q on audit, audit-syscall

[Chris Wright]

* Herbert Rosmanith (kernel@wildsau.enemy.org) wrote:
> 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.

Then grab the source, and read its READMEs.

> LSM depends
> on CONFIG_AUDIT* (this is correct, isn't it?)

No.

Re: Q on audit, audit-syscall

[Herbert Rosmanith]

> * Herbert Rosmanith (kernel@wildsau.enemy.org) wrote:
> > 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.
> 
> Then grab the source, and read its READMEs.

good point. I was reading netlink.c and libaudit.c. obviously the wrong
place ;-)
 
> > LSM depends
> > on CONFIG_AUDIT* (this is correct, isn't it?)
> 
> No.
> 

Re: Q on audit, audit-syscall

[Chris Wright]

* Herbert Rosmanith (kernel@wildsau.enemy.org) wrote:
> good point. I was reading netlink.c and libaudit.c. obviously the wrong
> place ;-)

There's a decent README with the audit (userspace) source.  And the
actual message format is documented in source code only AFAIK.

Re: Q on audit, audit-syscall

[Herbert Rosmanith]

> There's a decent README with the audit (userspace) source.  And the
> actual message format is documented in source code only AFAIK.

ok. thanks to all of you. I wasn't aware that netlink_audit is the
way to go and the others (/dev/audit, LAuS from IBM & SuSE) are obsolete.

and now, good night!

Re: Q on audit, audit-syscall

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

On Wed, 05 Apr 2006 23:47:24 +0200, Herbert Rosmanith said:

> 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.

One thing that's not at all clear from casual reading of the source code
of either the kernel or the userspace, or most of the existing docs...

The audit facility is *very much* an after-the-fact logging - there are a
few places where the code jumps through very odd hoops to deal with the fact
that by the time an actual notification is generated, the entire process that
triggered the event could be *gone*, completely and totally.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Q on audit, audit-syscall

[Stephen Smalley]

On Wed, 2006-04-05 at 23:47 +0200, Herbert Rosmanith wrote:
> > 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.

SELinux has a dependency on CONFIG_AUDIT these days because it uses the
audit system to log permission denials (originally just used printk, but
switched to the audit system when it was mainstreamed), but SELinux
doesn't depend on CONFIG_AUDIT for the actual access control checking
and enforcement.  SELinux just feeds data to the audit system for such
logging; it doesn't take any inputs from the audit system.

-- 
Stephen Smalley
National Security Agency

Re: Q on audit, audit-syscall: insecure?

[Linda Walsh]

Herbert Rosmanith wrote:
>  * The method for actual interception of syscall entry and exit (not in
>  * this file -- see entry.S) is based on a GPL'd patch written by
>  * okir@suse.de and Copyright 2003 SuSE Linux AG.
>   
===
    How does this audit method overcome the well known security
problem or race condition where one object is decoded and stored at
audit time, and a second, different object is used when the kernel
decodes the same arguments a second time, between which, user memory
has changed?

    I.e. -
    From this description, audit could store the filename used in an
"open" call by decoding the open arguments and recording
(copying from user-space into kernel space audit-buffer), then
return to the beginning of the code of the actual system call.
    Then a process on another CPU or an interrupting process on
the same CPU runs and changes the contents of the user-buffer.
    Then execution resumes in "audited" process and the "open" system
call decodes the arguments and copies the *different* filename from
the user space buffer into the kernel space buffer which the kernel
then uses for the call. 

    Usually, double-decoding of arguments is not just inefficient, but also
insecure because of this problem.  It's not practical to mask off interrupts
or halt all other CPU's to prevent them from accessing the user-memory
buffer. 

    The only safe way, that I'm aware of, is for "audit" to record
the arguments after the kernel has decoded and transferred them from
user space to kernel space.

    Is Linux's audit implementation secure or is it expected that it will
be vulnerable to these insecure race conditions?

    If it is vulnerable, the integrity of the audit records is known to
be suspect.  Such a system would not pass an open CAPP security evaluation.
However, if evaluators are properly misled, known-flawed
systems have been known to achieve CAPP and LSPP certification.  To my
understanding, it's not illegal to construct a certification plan such
that the certifier is led around such bugs.  It's also possible that
certifier doesn't know enough about the system to suspect such a problem.

The ethical preference would be to eliminate the race condition, but when
someone less ethical is in charge, it may not be your decision.  And if
a corporation, interested in the bottom line is running the priorities,
which would be cheaper?  On one hand you have the easy, two points of
insertion for auditing before and after the common system call vector,
    versus
spending the extra cycles (and $$$) to add calls for audit-recording in
every security relevant call, both at entry and exit points, then
testing the resulting code?

The second method is considerably more efficient because the security is
built into the kernel, instead of tacked on as an afterthought, but
$$$ often speak louder than ethics in a corporate/capitalist environment.

Linda