[lkml]   [2006]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Q on audit, audit-syscall
    > 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:
    > >
    > > 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

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

    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]
    > > Design.pdf
    > > [2]
    > > full_papers/edwards/edwards.pdf
    > > [3]
    > > [4]
    > 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

    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}:

    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.

    But on the other hand, we see kernel-options like CONFIG_AUDIT,
    argue this way? The attempt to review their statement is one
    reason for my email to LKML.

    > copies of the linux sources.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-04-05 22:11    [W:0.028 / U:102.348 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site