Linux Audit-Subsystem Design Documentationfor Kernel 2.6Version 0.1IBM/SUSE LINUX Confidential until Release of SLES9

ChangelogVersionDate0.12004 03 30AuthorsReviewerChanges, Problems, NotesThomasBiegeJan Beulich reflect new system hook designrevised ”How will events be generated?” sectionrevised ”What Information will be kept per Event?” sectionrevised ”Kernel Patch” sectionerased ”Single Point of Entry.” sectionrevised ”Audited System Calls” sectionrevised ”LAuS components”redraw some pictures

Copyright NotesSUSE LINUX and its logo are registered trademarks of SUSE LINUX AG.IBM and IBM logo are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.Linux is a registered trademark of Linus Torvalds.Solaris is a registered trademark of Sun Microsystems.UNIX is a registered trademark of The Open Group in the United States andother countries.Intel and Pentium are trademarks of Intel Corporation in the United States, othercountries, or both.Other company, product, and service names may be trademarks or service marksof others.The distribution and modification of this document is protected by the GNUFree Documentation Licence [4].Copyright c 2004 SUSE LINUX AG (is a Novell company)Copyright c 2004 Novell, Inc

AbstractThis paper describes the design of the Linux Audit Subsystem (LAuS), its components, its configuration and its CAPP compliance. LAuS was developed byNovell and SUSE LINUX to make Linux more secure and to attain the CC EAL4certificate.

Contents1 Introduction32 CAPP Requirements2.1 Audit Data Generation FAU GEN.2 . . . . . . .2.2 User Identity Association FAU GEN.2 . . . . .2.3 Audit Review FAU SAR.1 . . . . . . . . . . . .2.4 Restrict Audit Review FAU SAR.2 . . . . . . .2.5 Selectable Audit Review FAU SAR.3 . . . . . .2.6 Selective Audit FAU SEL.1 . . . . . . . . . . .2.7 Guarantees of Data Availability FAU STG.1 . .2.8 Action in Case of Audit Data Loss FAU STG.32.9 Prevention of Audit Data Loss FAU STG.4 . . .2.10 Management of the Audit Trail FMT MDT.1 .2.11 Management of audited Events FMT MDT.1 . .2.12 Reliable Time Stamps FPT STM.1 . . . . . . .3 High Level Design3.1 Why a Kernel-Patch? . . . . . . . . . . . . . . . . . . . .3.2 How can a Process be attached/detached to/from LAuS?3.3 How will Events be generated? . . . . . . . . . . . . . . .3.3.1 Kernel Source . . . . . . . . . . . . . . . . . . . .System Calls . . . . . . . . . . . . . . . . . . . .Filesystem Hooks . . . . . . . . . . . . . . . . . .Netlink Sockets . . . . . . . . . . . . . . . . . . .Process Creation and Termination . . . . . . . . .3.3.2 User Source . . . . . . . . . . . . . . . . . . . . .The PAM Framework . . . . . . . . . . . . . . . .Enhanced System-Applications . . . . . . . . . .3.4 What Information will be kept per Event? . . . . . . . .3.5 How will a unbroken Audit Trail be guaranteed? . . . . .3.6 How does the Audit Record reach the User-Space? . . . .3.7 How will the Audit Record be written? . . . . . . . . . .3.8 What about post-processing the Audit Record? . . . . 181818

3.9 Who can configure what in which way? . . . . . . . . . . . . . . .3.10 How is the configuration transferred to the Kernel? . . . . . . . .4 Low Level Design4.1 LAuS Components . . . . . . . . . . . . . . . . . . .4.1.1 Kernel Patch . . . . . . . . . . . . . . . . . .Login ID . . . . . . . . . . . . . . . . . . . . .Audit ID . . . . . . . . . . . . . . . . . . . . .Task Structure . . . . . . . . . . . . . . . . .Audited System Calls . . . . . . . . . . . . . .Filesystem Hooks . . . . . . . . . . . . . . . .Handling I/O Control Messages . . . . . . . .Handling IP Device and Routing Changes . .Device File . . . . . . . . . . . . . . . . . . .LAuS I/O Messages . . . . . . . . . . . . . .Filter . . . . . . . . . . . . . . . . . . . . . . .4.1.2 Audit Daemon . . . . . . . . . . . . . . . . .4.1.3 Audit Tools . . . . . . . . . . . . . . . . . . .4.1.4 Enhanced PAM Library and the PAM Module4.1.5 Enhanced System Applications . . . . . . . .4.2 LAuS Configuration . . . . . . . . . . . . . . . . . .4.2.1 Audit Daemon . . . . . . . . . . . . . . . . .4.3 LAuS Log Files . . . . . . . . . . . . . . . . . . . . .4.3.1 Contents of Audit Record . . . . . . . . . . .4.3.2 Raw Log Format . . . . . . . . . . . . . . . .4.3.3 Cooked Log Format . . . . . . . . . . . . . . 3A Abbreviations34B List of Figures36C Bibliography372

Chapter 1IntroductionThe purpose of this document is to describe the Linux Audit Subsystem (LAuS)low-level design and how it meats the requirements of Common Criteria EAL4SUSE LINUX Enterprise Server 9.Additionally this document serves as a communication platform for the development teams of IBM and Novell/SUSE to clarify design decisions and answeropen questions.3

Chapter 2CAPP RequirementsThe Controlled Access ProtectionProfile (CAPP) version 1d as released by theInformation Systems Security Organization [5] lists requirements for an auditsubsystem in a conforming system.This chapter describes how the CAPP requirements are met in the LAuSimplementation, along with additional requirements introduced in the SecurityTarget (ST).2.1Audit Data Generation FAU GEN.2CAPP specifies a set of audit data generation requirements in section FAU GEN.1.In general, there are two mechanisms used by LAUS to generate audit data.Messages can be generated in user–space by explicitly using laus log() andrelated library functions, and from kernel–space by intercepting system calls alongwith their arguments and return values, and generate audit events based on thisinformation as specified in the audit configuration files.The following table shows how the events required by CAPP are implementedby the LAuS system.Explicitly generated audit messages are listed in the format “Event TYPE subtype”,system calls generated uses the format “syscall name”. Note that some syscallshave several closely related variants, of which only the first variant is listed inthe table.: chmod includes fchmod open includes creat chown includes fchown, lchown, chown32, fchown32, lchown32 setuid includes seteuid, setreuid, setresuid, setuid32, seteuid32, setreuid32,setresuid324

setgid includes setegid, setregid, setresgid, setgid32, setegid32, setregid32,setresgid32Note that read and write system calls are not audited, because all DAC checksare done when opening the file, and also because the read /write calls do notcorrespond directly to program actions due to buffering done by the stdio . EventLAuS implementationFAU GEN.1 Start-up and shutdown of the auditfunctionsFAU GEN.2 NoneFAU SAR.1 Reading of information from the auditrecords.FAU SAR.2 Unsuccessful attemptsto read informationfrom the audit recordFAU SAR.3 NoneFAU SEL.1 All modifications tothe audit configuration that occur whilethe audit collectionfunctions are operating.FAU STG.2 NoneFAU STG.3 Actions taken due toexceeding of threshold.Events AUDIT start, AUDIT stop (from auditd)5.1.9FAU STG.4–FCS CKM.1 NoneFCS CKM.2FCS CKM.2FCS COP.1FDP ACC.1 None5.2.1Actions taken due tothe audit storage failure5syscall open (on the auditlog files)Like FAU SAR.1 (syscallopen), but with a negativeresultEvents AUDCONF reload(generated by auditd);syscalls open, link, unlink,rename, truncate (writeaccess to configurationfiles)EventAUDIT disklow(generated by auditd);execution of administratorspecified alert programEvent AUDIT diskfull (generated by auditd); execution of administratorspecified alert program; allaudited actions are blocked(process sleeps until spacebecomes available)

5.2.2FDP ACF.1 All requests to perform an operation onan object covered bythe SFP (filesystemobject or IPC object). RIP.2Note 1FIA ATD.1FIA SOS.1NoneNoneNoneRejection or acceptance by the TSF ofany tested secret.5.3.3FIA UAU.1All use of the authentication mechanism. UAU.7FIA UID.1NoneAll use of the useridentification mechanism, including A USB.15.4.1Success and failure ofbinding user securityattributes to a subject(success and failure tocreate a process).FMT MSA.1 All modifications ofthe values of securityattributes of namedobjects (files and IPCobjects).6syscalls chmod, chown, setxattr, link, mknod, open,rename, truncate, unlink,rmdir, mount, umount, msgctl, msgget, semget, semctl,semop, symlink, removexattr, shmget, shmctl ; detailsinclude identity of objectEventsAUTH success,AUTH failure (from PAMframework,“authentication” subtype)EventsAUTH success,AUTH failure (from PAMframework,“authentication” subtype)EventsAUTH success,AUTH failure (from PAMframework,subtypes“authentication”and“bad ident”); details include origin of attempt(terminal or IP address asapplicable)LOGIN audit record (frompam module oraurun); syscalls fork andclonesyscalls chmod, chown, setxattr, msgctl, semctl, shmctl MSA.3 Modifications of thedefault setting of permissive or restrictiverules.All modifications of the initialvalue of security attributes.FMT MTD.1 All modifications tothe values of TSFdata (create, deleteand clear the audittrail).FMT MTD.1 All modifications tothe values of TSF data(modify or observe theset of audited events).FMT MTD.1 All modifications tothe values of TSFdata (initialize andmodify user attributesother than authentication data).FMT MTD.1 All modifications tothe values of TSF data(initialize and modify user authenticationdata).5.4.7FMT REV.1 Revocation of user attributes5.4.8FMT REV.1 Revocation of objectattributes7syscalls umask, opensyscalls open, rename, link,unlink, truncate (of auditlog files)syscalls open, link, rename,truncate, unlink (of auditconfig files); event AUDCONF reload.“gpasswd” audit text messages (from shadow suite),details include new value ofof the TSF data“gpasswd” audit text messages (from shadow suite);attempts to bypass trustedprograms detected throughaudited syscalls open, rename, truncate, unlinkEvent: “gpasswd” audittext messages (from shadowsuite); attempts to bypasstrusted programs detectedthrough audited syscallsopen, rename, truncate,unlinksystem calls chmod, chown,setxattr, unlink, truncate,msgctl, removexattr, semctl,shmctl

5.4.9FMT SMR.1 Modifications to thegroup of users that arepart of a role.5.4.9FMT SMR.1 Every use of therights of a role (Additional/Detailed)5.5.1FPT AMT.1 Execution of the testof the underlying machine and the result ofthe test.FPT RVM.1 NoneFPT SEP.1 NoneFPT STM.1 Changes to the time.Event:syscalls(do )settimeofday,adjtimexFTP ITC.1 Set-up of trusted Event:syscall exec (ofchannel.stunnel program)–2.2Event: “gpasswd:” audittext messages “group member added”, “group memberremoved”, “group administrators set”, “group members set” (from trusted programs in shadow suite).The user’s actions result inaudited syscalls and the useof trusted programs that areaudited. Details include thelogin ID, the origin can bedetermined from the associated LOGIN record for thislogin ID and audit sessionID.Event: ADMIN amtu (generated by AMTU testingtool)User Identity Association FAU GEN.2To keep track of the owner of a process and to keep an audit trail for an interactiveuser session a “Login ID“ is associated with every process. The “Login ID“ getsinherited if a process spawns a new process. For example, this enables the SecurityOfficer (SO) to determine the real owner of a malicious process even if the userchanges his “User IDs“.2.3Audit Review FAU SAR.1LAuS provides a user space tool, aucat, that translates the on-disk binary formatto a human readable format at the request of an authorized administrator.8

2.4Restrict Audit Review FAU SAR.2The audit log file is protected by DAC controls so that only an authorized administrator is able to read the logs. The audit tools are also protected by DACcontrols so that only authorized administrators can invoke the tools.2.5Selectable Audit Review FAU SAR.3LAuS provides a user space tool, augrep, that allows the administrator to filterthe audit records to only display requested events. The administrator is able tofilter on: user group syscall file file operations outcome (success/failure) remote hostname remote hostname address audit ID syscall arguments2.6Selective Audit FAU SEL.1LAuS gives the administrator the ability to select the events to audit. This isdone by the administrator editing the filter configuration file of the audit daemon and then running auditd -r to notify the audit daemon of the change inconfiguration. The audit daemon in turn notifies the kernel of the new auditingpolicy.2.7Guarantees of Data Availability FAU STG.1LAuS prevents unauthorized deletion and modification of audit records via DACcontrols.9

2.8Action in Case of Audit Data Loss FAU STG.3If the system runs out of disk space, the audit daemon will stop reading fromthe device file which will result in filling up the buffers of the audit subsystem.Subsequently, the kernel will block any process trying to enqueue new audit eventsfor delivery to the audit daemon. To ensure that this blocking happens as soon aspossible, the audit daemon sets the message queue length to zero when detectingan out-of-space condition.2.9Prevention of Audit Data Loss FAU STG.4To avoid the loss of data, multiple ”bin files” are used. Each file has a fixed size.If one file is full, it will be locked and processed by external commands specifiedin the configuration file. During that time, the next bin file is used for storingaudit records. If the external command fails (exits with a non-zero exit status),the SO will be notified through syslog and the audit system will be suspended.2.10Management of the Audit Trail FMT MDT.1The LAuS log files can be added to the set of audited objects to detect maliciousmodifications of the audit trail. Furthermore, only the superuser is able to accessthe audit trail due to the appropriate DAC settings of the file(s).2.11Management of audited Events FMT MDT.1A user can not modify the set of audit events that is generated due to his or heractivity unless he is the superuser. Only the superuser is able to communicatewith the kernel and to modify the configuration files of the audit daemon.2.12Reliable Time Stamps FPT STM.1LAuS uses the system time and only the superuser is able to modify the systemtime.10

Chapter 3High Level DesignThe sections of this chapter try to clarify the abstract behavior of the LinuxAudit subsystem. The sections are ordered by data flow to make it more logicalto the reader to understand.(Please note that every action to configure or modify the audit subsystem hasto be done with capability CAP SYS ADMIN (root user))3.1Why a Kernel-Patch?The vanilla 2.6 Linux kernel does not provide a mechanism to trace syscalls in thedesired way, nor does it contain the capability to track processes and generate anaudit trail. Due to this lack of functionality the Linux kernel needs to be patched.The patch enhances internal kernel structures to keep track of the process andprovides an interface to the user space by defining I/O control commands and adevice file.Beside file–system DAC controls of the audit device file the kernel patch restricts access by verifying if the caller of an I/O control command has the capability CAP SYS ADMIN.3.2How can a Process be attached/detachedto/from LAuS?A process can only attach itself to the audit subsystem and only if it has root(CAP SYS ADMIN) privileges. Attaching is done by either directly using I/Ocontrol commands or by using LAuS library functions. Several attributes, suchas the “Login ID“ and the “Audit ID“ are bound to the attached process.Whenever an audited process forks a child process, the child process inheritssome attributes of the parent process to make the audit trail continuous.11

Likewise, the only instance that can detach a process is the process itself, andonly if it has root privileges (CAP SYS ADMIN). When detaching, all sessioninformation (such as the the Login ID and Audit ID) is lost.Another way of detaching is to exit. Whenever a process terminates/abortsit will be detached from the audit subsystem, too.In addition, a process is permitted to suspend and resume auditing. Again,this is achieved through I/O control commands to the audit subsystem, andrequires administrative privilege (CAP SYS ADMIN). This functionality is forthe benefit of trusted applications that wish to generate a single high-level auditevent describing their actions, instead of several system call events.The major difference between suspending and detaching is that the formerretains all session information, including the “Login ID“ and “Audit ID“. Thesuspend flag is not inherited to child processes, that is, if a process suspendsauditing and forks a new child process, that child will be subject to auditing asusual.A trusted application such as the passwd utility, for instance, suspends auditing before updating the password database, and generates a single record indicating the (attempted) password change afterwards.3.3How will Events be generated?There are two kinds of sources for an audit event, the kernel and user applications.The main source is the kernel space. System calls, file access and network layeractions are handled by the kernel. Netlink operations are logged on completion.System call arguments are normally logged inside the call at the beginning of thefunction, return codes are logged at the end of the system call. adjtimex(2) arguments will differ at beginning and end of the call. chroot(2) needs to process the filename in the context of the original file–system root, not the changed one after the system call. execve(2) never returns, and the process image will be gone as soon as thesyscall is finished. ioctl(2) arguments will differ at beginning and end of the call. rename(2) needs to save the first argument before the call, it will be invalidafter completion of the syscall. unlink(2) needs to process the filename argument before the file is deleted.Access to file–system objects is logged indirectly through hooks in the VirtualFile System (VFS).12

User applications have the option to generate their own, more abstract, auditrecords, as a replacement or enhancement for the low-level syscall-based records.For example, the passwd(1) utility should write a single notification of the password change instead of several low-level operations on the password files. To dothis, trusted programs can suspend syscall auditing and send user messages tothe kernel using the audit device. The kernel will add its headers and attributes,then pass the message on to the audit daemon through the device file.Every event generated by the kernel contains information on the process onbehalf of which the kernel generates the event, including the current UID, GID,the “Login ID“ and “Audit ID“, etc. This fixed portion is followed by a variabledata portion, depending on the message type.Event messages are placed into a queue, from where they can be retrievedby the audit daemon through the read system call, one record at a time. If thelength of the queue exceeds a certain prespecified limit (adjustable via the sysctlkernel interface), any processes trying to generate new events will be blocked untilthere is space in the queue again. The default maximum size of the queue is 1024entries with 8 KB per entry.3.3.1Kernel SourceEvent:System CallEvent:NetlinkEvent:VFSAudit HooksFilteringFilter tableKernel Bufferaugrep, aucat, .Device Fileread(),configurebinary logdataAuditDaemonLogsFigure 3.1: Data Flow: Kernel Sources13

The kernel patch creates several hooks for monitoring process creation/termination,VFS usage, and system calls entry/return, as well as a hook to track modificationsof the system’s network configuration.System CallsAs stated before a sysem call will be intercepted at the beginning of the code andat the various return points (different errors). System call events will be generatedfor every traced process as long as the filter policy does not discard it. Thefilter policy can be a simple yes/no statement, but complex Boolean expressionsinvolving properties of the process, as well as the system call arguments, arepossible, too.If the system call passes the filter rules, an audit event will be generated.This event data includes information about the process, system call number, thereturn value (outcome), and a TLV (tag/length/value) encoded representation ofthe system call arguments, where applicable. (For instance, the argument datato a number of ioctl calls are included, but data passed to the write system callis generally not included).Filesystem HooksTo log the usage of filesystem objects the kernel patch relies on a prerequisitepatch to the VFS code modifying functions like open, truncate, chdir and soon. The modifications of these functions are similiar to those of the system calls;intercept functions are inserted at the beginning and end of a monitored VFSfunction.Netlink SocketsThe Linux kernel network code can be controlled either by using the ioctl(2)system call of by using a netlink socket. The first case is handled as describedabove in sub-section “System Calls“. The latter case needs special handling. Tobecome aware of netlink messages the kernel patch needs to apply another hookin the kernel. LAuS only observes netlink routing messages because these are theones we are interested in. To get the result of the message processing the audithook is triggered right after the message had been processed. The message data,message length and the outcome will be logged.Process Creation and TerminationThe audit subsystem can generate audit events for process creation (includingprocesses generated by fork and clone, but also for kernel threads), and process termination. For both events, filter policies can be configured to select justspecific events (such as processes exiting due to a signal).14

3.3.2User tSubsystemDevice FileKernel Bufferread()binary logdataAuditDaemonLogsFigure 3.2: Data Flow: User SourcesIn addition to the kernel, user space applications should be able to generatetheir own, more descriptive, audit records. This type of records is called “AuditUser Messages“. Two types of user applications need this special feature:a. applications that authenticate users and/or change privilegesb. applications that change the configuration of the systemThe first group of applications can be served by a special PAM library and aPAM module. The PAM library and the module attach the current processand set various attributes like the “Login ID“, the terminal name, hostname, IPaddress and alike through a special Audit Login Message . The PAM module can””serve as an authentication, account or session module. It is used as workaroundfor applications that handle authentications apart from PAM but use the PAMframework for other tasks.The latter group of applications needs to be modified manually to handle theLAuS interface to the kernel and to send the “Audit User Messages“.15

The PAM FrameworkThe PAM module is used together with the modified PAM library patch to activate the audit subsystem for the current application. The module is responsiblefor the following tasks: open the audit device file if configured to do so, detach the current audit data attach the current process to the audit subsystem close the audit device fileThe PAM Library is patched to write audit logs for success and failure returned by the PAM module stacks called on behalf of applications. The libraryframework is responsible for the following tasks: open the audit device file emit an “Audit User Message“ indicating success or failure on successful authentication, set the login UID for the process and emit an“Audit Login Message“ close the audit device fileThe kernel does not care about the format of the “Audit User Messages“, itjust adds the attributes and header to it and puts it in the audit record queue.All system applications that handle authentication for changing user privilegesare linked against the PAM library. Therefore the PAM library provides a centralpoint for handling LAuS operations.Enhanced System-ApplicationsAll system applications that change the system configuration need to be modifiedto notify the SO about the changes they made. This does not need system callauditing, so the trusted application can suspend auditing and perform their ownlogging. To accomplish this task just a few lines of code need to be added:1. open LAuS interface2. suspend auditing3. format user message and send it to the kernel4. close LAuS interface16

3.4What Information will be kept per Event?Additional information is generated and stored with each event. The followinglist gives an overview (please note: some informations are accessed indirectly byreferencing the “Audit ID“): Timestamp: Every audit record is timestamped Login ID: User ID of the user authenticated by the system Audit ID: unique 32 bit identifier Login Message:– Hostname: Remote host name in case of remote login– IP Address: IP address of remote host in case of remote login– Service: Name of service that authenticates the user Text Message:– arbitrary User-Text System Call:– System call name– Arguments– Result/Outcome3.5How will a unbroken Audit Trail be guaranteed?To guarantee a continuous audit trail, three mechanism will be used: Putting audited processes to sleep when the audit record buffer is full orsomething is wrong with the log file. pre-allocated bin files or alternatively: monitoring disk-space while in stream- or file- mode andnotify the SO if threshold is reached.17

3.6How does the Audit Record reach the UserSpace?First the audit daemon has to register itself to LAuS to receive all audit records.The audit records themselves are written to an internal queue and can be read,one at a time, from there by invoking the read system call on the audit devicefile. The audit daemon is the only process that is able to read these records.Every record read will be deleted from the queue to free memory for new ones.3.7How will the Audit Record be written?After the audit daemon reads an audit record from the device file it will addanother header containing just a timestamp. The payload data will not be processed in any way. Therefore the audit log just contains the time and the binarydata that was directly read from the kernel.3.8What about post-processing the Audit Record?Tools like aucat use various library functions to parse the binary audit log andoutput it in a human readable form. These library calls can be used by everyapplication that wants to postprocess the log files.18

3.9Who can configure what in which way?auditd ConfigFilesAuditDaemon4.)updateAudit SubsystemFigure 3.3: Data Flow: ConfigurationBy using the DAC controls of the file–system only the users (typically root)with capability CAP DAC OVERRIDE or CAP DAC READ SEARCH are allowed to access and modify the configuration file of LAuS. The only componentof LAuS that uses configuration files is the audit daemon. The audit daemonneeds a main configuration file for defining thresholds and corresponding actionsetc, and two files for defining filter rules and filter object sets.These configuration files need to be modified directly by using a text editor and can be made effective by running auditd -r. This command sends areload message (HUP signal) to the running auditd process, which will re-readthe configuration and reload it into the kernel. DAC controls ensure that onlythe root user is able to modify these files and use auditd -r, additionally theaudit subsystem only accepts messages generated by user root.3.10How is the configuration transferred to theKernel?The audit daemon reads the configuration files, parses them and sends the filterrules to the kernel by using a special I/O control command. The filter rules19

are part of the kernel now and can only be modified or cleared by a user withsufficient administrative privilege (CAP SYS ADMIN).20

Chapter 4Low Level Design4.1LAuS ComponentsThe core component of LAuS are two kernel patches to enable file–system hooksand system call logging (partially based on the former), filtering, checking networktraffic and keeping track of user activities. In addition, it contains an audit daemon to handle kernel messages, several command line tools, LAuS API libraries,a modified PAM subsystem, a PAM module, and modified system applications.The following diagram is an overview of the LAuS components:aucataugrepLibrary APILibrary APILog DataConfigurationApplications withPAM supportlogin,passwd,useradd, .AuditDaemonLibrary APIread()ioctl()Linux Kernel 2.6 with LAuSFigure 4.1: LAuS Overview21

4.1.1Kernel PatchThe native Linux kernel does not contain any mechanism to monitor system callsand to keep track of user activities. Therefore the Linux kernel has to be enhancedto provide the SO with an audit trail.The kernel patch modifies the process task structure for storing additionalinformation/attributes, adds intercept functions and an additional flag to theptrace framework, provides an interface to the user space, and applies filter policies. All these tasks will be described in the following subsections.Login IDIn order to fulfill the CAPP requirements, the kernel must be modified to track the“Login ID“ for each pro

down of the audit functions Events AUDIT start, AU-DIT stop (from auditd) 5.1.2 FAU GEN.2 None 5.1.3 FAU SAR.1 Reading of informa-tion from the audit records. syscall open (on the audit log les) 5.1.4 FAU SAR.2 Unsuccessful attempts to read information from the audit record Like FAU SAR.1 (syscall open), but with a negative result 5.1.5 FAU SAR .