> 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_ andI've _exactly_ described what I am looking for: for description ofinterfaces and software.  I cannot find good (if any) documentation onthis (see below), neither via google, nor by examining thekernel-sources.You see, I am asking for documentation. I am not asking "please solve myproblem."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 sayingthat "if something does not make sense for you, that doesnt mean that it wontmake 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 devicedevices.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 hitsin RCU/listRCU.txt mostly, which doesnt seem to deal with auditing. In myexperience, 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 totrace syscalls in the desired way, nor does it contain thecapability 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 & SuSEargue this way? The attempt to review their statement is onereason 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-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at  http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at  http://www.tux.org/lkml/