e-dokumen.com

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)5.5.25.5.35.5.4–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 .