LWIOD Access Audit Module

LWIOD Access Audit Module Andrew Pilloud andrew.pilloud@isilon.com Last updated: June 24, 2010 Current Revision: Abstract Current releases of OneFS use Samba to provide CIFS protocol support. Samba has an audit module to record network file access through the CIFS protocol. As of OneFS 6.5 Chopu the Samba based server will be removed. The replacement for Samba does not have any auditing ability, and work on auditing in the filesystem will not begin until after the release of Chopu. The goal of this project is to provide a stopgap auditing system until such time that auditing is available in the OneFS filesystem. 1

Contents 1 Samba Full Audit 4 1.1 Log Format......................................... 4 1.2 Common VFS Operations................................. 4 1.2.1 connect and disconnect.............................. 4 1.2.2 opendir and closedir................................ 4 1.2.3 create file...................................... 4 1.2.4 close......................................... 5 1.2.5 rename....................................... 5 1.2.6 mkdir, rmdir, and unlink............................. 5 1.2.7 chmod and sys acl................................. 5 2 Windows Auditing 5 2.1 Log Format......................................... 5 2.2 Network Events....................................... 5 2.2.1 Logon........................................ 5 2.2.2 Logoff........................................ 6 2.2.3 File Share...................................... 6 2.2.4 Detailed File Share................................. 6 2.3 Object Events........................................ 6 2.3.1 Object Open.................................... 6 2.3.2 Object Close.................................... 6 2.3.3 Object Delete.................................... 6 2.3.4 Object Access.................................... 7 3 Customer Use Cases 7 3.1 Customer Requirements.................................. 7 4 LWIOD Access Audit Module 7 4.1 Log Format......................................... 7 4.2 Network Events....................................... 8 4.2.1 Logon........................................ 8 4.2.2 Logoff........................................ 8 4.2.3 File Share...................................... 8 4.3 Object Events........................................ 8 4.3.1 Open........................................ 9 4.3.2 Close........................................ 9 4.3.3 Delete........................................ 9 4.3.4 Access........................................ 9 4.3.5 Rename....................................... 10 4.4 Logging Example...................................... 10 4.5 Configuration........................................ 10 4.5.1 Logging of messages................................ 10 4.5.2 Global Enable................................... 10 4.5.3 Global SACL.................................... 11 4.6 Interaction with LWIOD.................................. 11 4.6.1 Network Events................................... 11 4.6.2 Object Events................................... 11 5 Differences between full audit and the new audit module 12 5.1 Event message translation table.............................. 13 2

6 Differences between Windows Auditing and the new audit module 15 7 LWIOD Access Audit Module API 15 7.1 Global Enable configuration................................ 15 7.2 Global SACL configuration................................ 16 7.3 libaudit........................................... 17 7.3.1 AuditAlarm().................................... 17 7.3.2 LogonAuditAlarm()................................ 17 7.3.3 LogoffAuditAlarm()................................ 18 7.3.4 FileshareAuditAlarm()............................... 18 7.3.5 ObjectAuditAlarm()................................ 18 7.3.6 ObjectOpenAuditAlarm()............................. 19 7.3.7 ObjectCloseAuditAlarm()............................. 20 7.3.8 ObjectDeleteAuditAlarm()............................ 20 7.3.9 ObjectAccessAuditAlarm()............................ 20 7.3.10 ObjectRenameAuditAlarm()........................... 21 List of Tables 1 full audit to LWIOD audit translation table....................... 13 3

1 Samba Full Audit The Samba vfs full audit module[?] is a samba module with the ability to log the complete set of VFS operations out to syslog. That is to say it will log almost any file operation executed by Samba. The Full Audit module can be configured to only log a select set of these operations on their success or failure. Events are logged to syslog with a configurable facility and priority. 1.1 Log Format The event log is in the format of PREFIX OPERATION RESULT FILE, with fields separated by the pipe character, as illustrated. The OPERATION and RESULT fields are always single fields, however the PREFIX and FILE fields are more complicated and can contain their own pipe delimiters. The OPERATION field contains the name of the vfs operation the event pertains to. The RESULT field contains the keyword ok or failure depending on the result of the operation. A failure keyword is followed by a text explanation of the error in the RESULT field. The PREFIX field is a configurable string of samba standard substitution variables[?]. In the default Isilon configuration[?] it is set to %u %I %S, which logs the effective user, client IP, and share name. However this field can be customized with a wide variety of options, including desired user, server or client hostname, protocol level, domain, remote architecture, process id, and share root directory. The FILE field varies based on the vfs operation[?]. Like the PREFIX field it can contain multiple subfields, separated by the pipe symbol. The last subfield is always the file or share name the operation is occurring on. 1.2 Common VFS Operations There are currently 113 VFS operations, however only use a small subset of these are useful in a security auditing context. The following VFS operations are generally considered useful and are grouped by their actions as well as the content of their FILE field. 1.2.1 connect and disconnect The connect and disconnect VFS operations are triggered by share level connections. These operations are generated as a result of a tree connect or tree disconnect operation. This is the only case where the FILE field does not contain the path to a file, instead the name of the share being interacted with is provided. 1.2.2 opendir and closedir The opendir operation are a result of opening a directory for a directory listing. The closedir is the completion of that operation. The FILE field for both contains the share relative path to the directory prefixed with a period and backslash. Just a period is given for the root of the share. 1.2.3 create file The create file operation is one of the most complex, and most useful. Most operations involving opening or creating files or directories can be done through create file. As a result, this operation has many details in its FILE field. The first subfield is the access mask. The access mask is the standard windows access mask represented as a hexadecimal number. The second field is the object type. This field can be file or dir to indicate which type of object has been opened. The third field is the operation type. This field indicates if the object was created or just opened. The last field is the share relative path to the file or directory. It can also be a period to represent the root of the share. 4

1.2.4 close The close operation indicates the closure of a file opened by an operation such as create file. Only the file or directory path is present in the FILE field. As in create file the path is the share relative path, or a period for the root of the share. 1.2.5 rename The rename operation can occur when a file or directory is renamed. The FILE field contains two subfields: the first being the old name, the second being the new name. Both paths are share relative. 1.2.6 mkdir, rmdir, and unlink The operation mkdir is used to make a directory, rmdir to remove a directory, and unlink to remove a file. These three operations contain only a share relative path to that target in the FILE field. 1.2.7 chmod and sys acl Commands prefixed with chmod or sys acl act on the permissions of a file or directory. For this set of commands, the FILE field contains only a share relative path to the target. From the full command name you can determine if permissions are being read, written, or cleared. However, the exact bits being changed are not provided. 2 Windows Auditing Windows Auditing is a complete system which has several hundred different event types[?] covering all parts of a windows system. All events are logged to the windows security log and contain a large amount of information about the system and process that generated the event, and details about the event itself. 2.1 Log Format The Audit Event Log is stored in the standard Windows XML Event Log Format[?]. It is stored in the security log file and was designed to be queried for events by applications in real-time using the event query API. Some fields contained in a typical event include EventID, Version, Keywords (Success or Failure), a time stamp in microseconds, sequence number, generating computer, effective user SID, effective username, effective domain, and a LogonID. Most of these fields are self-explanatory. The effective user fields contain information about the user performing the action, and the LogonID is a connection unique identifier. 2.2 Network Events The four network events are Logon, Logoff, File Share, and Detailed File Share. Of these events, all except for Logoff include a source IP address, and source port. 2.2.1 Logon The Logon event indicates the connection of a new user. The Logon event includes the additional fields of source computer name, target user SID, target username, target domain name, and target LogonID fields. These fields indicate the user who has just authenticated. The target LogonID is 5

the unique value that will be used in the LogonID of all following events generated by the connection until Logoff. For the logon event the effective user fields are S-1-0-0 and LogonID is 0 because the thread has no effective user before logon. Logon Failure is actually a different event, however the only difference is the EventID and the addition of a reason for failure. 2.2.2 Logoff The Logoff event indicates the end of the session tracked by the effective LogonID of the event. This event does not contain any fields beyond the standard and network fields. 2.2.3 File Share The File Share event indicates a file share has been accessed. It occurs on the tree connect of the share. In addition to the general and network fields, it includes the share name, share path, access mask, and an access list. The access list is a string containing tokens representing the bits of the access mask. This field is not fully documented. 2.2.4 Detailed File Share There is also a Detailed File Share event. This event is new to Windows 2008 R2, and is preferred over the regular File Share event by the system. This event occurs whenever a file or directory on a share is accessed. It does override the regular event so both events will not occur. However, special shares such as IPC$ do not have files so the regular File Share event is used for accesses to those shares. The Detailed File Share event includes all fields found in File Share event with the addition of the share relative target path and an Access Reason field. The Access Reason field details why each bit of the Access Mask passed or failed the access check. Its format is the Access List format with a result token and a Security Descriptor String for each entry in the Access List. 2.3 Object Events The second set of events are the file events. This set includes Object Open, Object Close, Object Access, and Object Delete. All four events include the regular target fields as well as an object type and unique HandleID. For the purpose of these events both file and directories are file type objects. For file objects, the HandleID is a system wide unique identifier for each open file. 2.3.1 Object Open The Object Open event occurs when a file or directory is opened for any reason. It includes fields for the full local path to the object, the Access Mask, Access List and Access Reason. The Access fields are the same as the ones found in Detailed File Share event. The HandleID associated with the open event will be used to identify the object until a Close or Delete event. 2.3.2 Object Close The Object Close event has no special fields. It only contains the standard and object event fields. The Close event indicates the closing of an object and the end of use of the HandleID. 2.3.3 Object Delete Like the Close event, the Object Delete event has only the minimal set of fields. The Delete event indicates complete deletion of an object. It only occurs when the file is completely removed from the system. Rename trigger an Access event with the Delete permission, not a Delete. 6

2.3.4 Object Access The final event applied to objects is the Object Access event. This event occurs the first time requested bits in the requested access mask are exercised on an object. So, if a file is opened with full access, an Access event will occur the first time it is read from and again the first time it is written to. The Access event includes all fields found in the Open event except for the Access Reason. 3 Customer Use Cases The primary customer use for full audit is to log access to files stored on the system. They are interested in when files were accessed and by whom. Most customers only look at the logs after data theft occurs. They primarily log the following types of operations: connect, disconnect, open, close, create, rename, and remove. Some customers use a third party log analysis program. This program reads in and analyses our syslog output. The third party program keeps track of the timestamp, username, IP address, server, file path, operation, and operation count after processing the log. The VFS operations are abstracted to a limited set of operations: read, write, rename, and delete. 3.1 Customer Requirements At minimum the following must be logged: file or directory path, username, domain name, client IP, server IP, date, share name, operation name, and operation status. The principal name, path, and share name must support internationalization via UTF-8. The Desired features include a year in the date and logs in the Microsoft Windows event log format. Many customers also desire control over which events are logged on the success or failure of an operation. The new implementation will include the minimum requirements and control over which events are logged. It will not include the desired changes to the timestamp or logging format. 4 LWIOD Access Audit Module The new LWIOD Access Audit Module is designed to replace the Samba full audit module as a stopgap until auditing is available in the OneFS filesystem. It is modeled after the Windows Auditing system while still maintaining support for all customer use cases of the full audit module. The VFS operations will be abstracted to a set of eight events which cover both network and object (file and directory) operations. 4.1 Log Format Month DD HH:MM:SS clustername-n(id1) processname[#]: UserSID 0xSessionID Event Result[ Event Specific] The new logging module will still use syslog to output data. As before, syslog will provide the time-stamp and server hostname. The payload of the log message will continue to use the pipe symbol as a delimiter between fields. The standard log entry will be in the following order: user SID, session id, event, result, event specific. Except for the event specific field, each field represents a single piece of data. The user SID field will contain the effective user s SID. The session id field containts an id number unique to the logon session. The event field will be a text name for each event. The result field will contain the ntstatus of the operation in its text form. For example STATUS SUCCESS will indicate 7

the operation was a success. The event specific field is specific to each event and will be detailed later on. 4.2 Network Events The first set of events are network related. These events pertain to the high level network operations and occur for each network connection. 4.2.1 Logon Month DD HH:MM:SS clustername-n(id1) processname[#]: UserSID 0xSessionID LOGON Result ServerIP ClientIP PrincipalName The Logon event is used to indicate the beginning of a session. It occurs after authentication on a new connection. Unlike the windows event, this event is used for both success and failure. This event has additional fields containing the server IP, client IP, and PrincipalName. This event represents the creation of a new session. The session id associated with this event will be used with all future events associated with this connection until it is terminated. The PrincipalName is the requested username as provided by the client before any server side account mapping. They will contain the details of the account that is being used. This event will need to be processed in order to know the source IP of the client in future events with the same session id. 4.2.2 Logoff Month DD HH:MM:SS clustername-n(id1) processname[#]: UserSID 0xSessionID LOGOFF Result The Logoff event is used to indicate the termination of a session. It occurs when a successfully authenticated connection is closed. This event s log entry contains no additional data fields. 4.2.3 File Share Month DD HH:MM:SS clustername-n(id1) processname[#]: UserSID 0xSessionID FILESHARE Result 0xMASK ShareName The File Share event indicates the tree connect of a network share. This event occurs whenever a tree connect is attempted. It contains two additional fields: the first is the maximal access mask in hexadecimal and the second is the share name. 4.3 Object Events Month DD HH:MM:SS clustername-n(id1) processname[#]: UserSID 0xSessionID Event Result 0xHandleID[ Event Specific] The Object Event set contains all events relating to file and directory access. These events also share a common set of event specific subfields before their individual specific fields. Each object event contains the handle ID field as its first event specific subfield. The handle ID is a unique identifier associated with each file session. 8

4.3.1 Open Month DD HH:MM:SS clustername-n(id1) processname[#]: UserSID 0xSessionID OPEN Result 0xHandleID 0xMASK Type Operation ShareName AbsolutePath The Open event occurs when a file or directory is opened or created. It indicates the beginning of a file session. The handle ID associated with this event will relate to this file session until the close event with the same handle ID. The Open event contains the following subfields: access mask, object type, operation, share name, object path. The access mask field is the requested access mask, unless maximal access is requested and the operation succeeds. In that case the access mask will be the granted access mask. The object type field indicates what type of object is being accessed. The two values in this implementation will be FILE or DIR to indicate a file or directory respectively. The operation field will indicate what operation was taken. This field is taken from the disposition and can be one of the following five values: FILE SUPERSEDE, FILE OPEN, FILE CREATE, FILE OPEN IF, FILE OVERWRITE, and FILE OVERWRITE IF. The share name is the name of the share accessed, and the object path is the absolute path to the object on the server file system. 4.3.2 Close Month DD HH:MM:SS clustername-n(id1) processname[#]: UserSID 0xSessionID CLOSE Result 0xHandleID The Close event occurs when a file or directory is closed. It indicates the end of the file session. The handle ID is the only field and this event marks the end of its use with the opened file. 4.3.3 Delete Month DD HH:MM:SS clustername-n(id1) processname[#]: UserSID 0xSessionID DELETE Result 0xHandleID The Delete event indicates a file or directory has been marked for deletion from the file system. This event has no additional subfields. The Open event with the same handle ID indicates the file which has been marked for deletion. This event occurs immediately before the close event of a file open with the delete on close flag set or when the file disposition delete flag is set. Unlike the windows implementation, this event only occurs if the delete flag changes state rather then every time it is set. 4.3.4 Access Month DD HH:MM:SS clustername-n(id1) processname[#]: UserSID 0xSessionID ACCESS Result 0xHandleID 0xMASK The Access event is triggered the first time permissions on an open object are exercised. For example, the first time an open file is read this event will occur and then again the first time it is written. Failures are tracked independently of successes and are also reported once per access mask bit per open file. This event contains the additional subfield of an access mask. This access mask is in hexadecimal form and indicates which operations were exercised on the file. The Open event must be referenced for complete file details. 9

4.3.5 Rename Month DD HH:MM:SS clustername-n(id1) processname[#]: UserSID 0xSessionID RENAME Result 0xHandleID NewAbsolutePath The rename event indicates the rename of an object. It includes the addition of the full path to the file after rename. This does not imply the end of a file session, and any additional operations on the same handle ID are occurring to the renamed file. The Open event with the same handle ID can be used to determine the original file name. Be aware, there are many ways to perform a rename. This event will only occur on a direct rename command. As a result, it is possible to rename a file without triggering the rename event. 4.4 Logging Example The following example demonstrates log messages that could be generated if the user admin connected to node 1 on a cluster named clustera and then attempted to delete the README.txt file twice. The indented lines are for document formating reasons; in the actual log each entry will be contained on one line. May 31 13:12:11 clustera-1(id1) lwiod[2246]: S-1-22-1-10 0x2841F500 LOGON STATUS_SUCCESS 127.0.0.1 127.0.0.2 CLUSTERA-1\admin May 31 13:12:11 clustera-1(id1) lwiod[2246]: S-1-22-1-10 0x2841F500 FILESHARE STATUS_SUCCESS 0x1301BF ifs May 31 13:12:11 clustera-1(id1) lwiod[2246]: S-1-22-1-10 0x2841F500 OPEN STATUS_SUCCESS 0x2840A470 0x10080 FILE FILE_OPEN ifs /ifs/readme.txt May 31 13:12:12 clustera-1(id1) lwiod[2246]: S-1-22-1-10 0x2841F500 DELETE STATUS_SUCCESS 0x2840A470 May 31 13:12:12 clustera-1(id1) lwiod[2246]: S-1-22-1-10 0x2841F500 OPEN STATUS_OBJECT_NAME_NOT_FOUND 0x0 0x10000 FILE FILE_OPEN ifs /ifs/readme.txt May 31 13:12:12 clustera-1(id1) lwiod[2246]: S-1-22-1-10 0x2841F500 LOGOFF STATUS_SUCCESS 4.5 Configuration There are three configurable parts of the lwiod access audit module. These options are the location messages are logged to, the global enable settings for network operations, and the global SACL for file operations. 4.5.1 Logging of messages Unlike full audit, the syslog facility and level will not be configurable. This implementation will use a new facility named AUDIT and the log level will be LOG INFO. With the introduction of a dedicated facility, the reconfigurability of these values provides little benefit to the user. Syslog will be configured to store the audit logs in /var/log/audit/lwiod.log. Relocation can be achieved manually with a symbolic link as the audit directory. 4.5.2 Global Enable The network events will be enabled through two options in the srv global configuration. These options will be audit-logon and audit-fileshare. They will configure the logon and fileshare event 10

respectively. These two options will be configured to one of four values: none, success, failure, all. None will disable all logging, success will log all events with the NT SUCCESS macro returning true, and failure will log all other events. Both success and failure events will be logged when the option all is chosen. The logoff event will share the configuration settings from logon. These options will be configured through the isi smb config global command. 4.5.3 Global SACL The global SACL will be configured in the onefs lwio module and stored in the registry as a binary security descriptor. It will be passed into the open audit function. The global SACL will have two aces belonging to everyone of the SYSTEM AUDIT ACE TYPE. One will have SUCCESS- FUL ACCESS ACE FLAG set and the other will have FAILED ACCESS ACE FLAG set. The access rights set on each ace will indicate what audit events are logged on success and failure. A success is defined by the NT SUCCESS macro returning true on the return status. All other events are considered failures. The global SACL will also be configured through the isi smb config global command. The details of how this will be accomplished are awaiting the resolution of bug 66327. The global SACL will live in two variables: audit-success and audit-failure. The permission bits will be represented as a comma separated list like ls -le does. Where there exists a different meaning for an access right bit when applied to a file or directory, the two labels can be used interchangeably. For example, setting execute or traverse in audit-success will have the same result because they are the same bit. When the variables are read, the names for file permission bits will be displayed. While we have the ability to store the SACL as part of a file s security descriptor, it is untested and significantly complicates the configuration of the auditing module. At this time the global SACL will be used instead. If in the future it becomes desirable to pass in a file based SACL rather then a global SACL, the module API will handle it with little to no change. 4.6 Interaction with LWIOD The new audit module will exist in the form of a library. It will be called from functions in both srv and the onefs driver inside the lwiod application. The library will then generate the appropriate log messages and send them to syslog. Configuration details will be stored in the standard registry backed configuration structures of lwiod. 4.6.1 Network Events Network events will be generated in the Srv module. It will store the global network logging enums and pass those into the audit library. The Srv module will call the audit module on connect, disconnect, and share connect events. 4.6.2 Object Events Object events are to be generated in the onefs filesystem driver. On create, a session ID will be passed in from Srv as an extra create parameter. It will need to be stored in the Ccb for use with audit events. The AuditMaskSuccess and AuditMaskFailure variables are bitmasks that will be stored in the Ccb. They will initialy be set by the object open event and will be updated on calls to the object access event. The onefs driver will also store the Global SACL which it will pass into the audit library on open events. 11

lwiod srv Config onefs Global SACL syslogd libaudit.so Figure 1: Block Diagram 5 Differences between full audit and the new audit module The primary difference between the Samba full audit module and the new auditing system is the abstraction of VFS operations into events. Some VFS operations translate directly to events. For example the connect VFS operation becomes the File Share event. Most file operations translate to the Open or Access events. For example, mkdir translates to open with a type of dir and an operation of create. Some data is lost in this translation. Before, every write operation would be logged. Now only the first write each time a file is open is logged. However, there is no loss of useful information. A single write operation could change the whole file and thousands of write operations can only change one bit. Exactly what is written has never been logged and without this information no additional knowledge is gained by logging the first write over all writes. Another loss of data is as a result of multiple operations mapping to the same event. Both sys acl add perm and sys acl clear perms map to an Access with the Write Permissions bit being set in the access mask. Like with write operations, this loss of information is more of a benefit then a hindrance. Without knowing exactly what data is being changed, the knowledge of what operation is occurring is no benefit outside of debugging. While not losing any useful data, this change simplifies management and log review by combining all operations that might change the ACL into one event that can be more easily searched for and enabled. The change with the biggest impact is that events are not atomic. A single event (except for the Logon event) no longer provides a complete set of details about who conducted an operation on what. For example, to see which user changed the ACL on a file you need three events. The Access event is required to determine an ACL was changed. From that event, the Logon event of the same session ID is required to determine the username and the Open event of the same handle ID is required to determine which share and file was acted on. However, this behavior is similar to that of windows. This change is of minimal impact, as it would only require two additional greps for 12

manual searching of the logs, and would be trivial to implement in a log analysis program powered by a relational database. The effective SID is present in all events. Depending on username to SID mapping the open events may still be useful on their own. However, if network information is required, the audit-logon parameter must be set to success or all. Per share configuration granularity is lost in the new audit module. However, there is no known use case, so the additional configuration options are likely to be more confusing then helpful. 5.1 Event message translation table Table 1 is a translation between full audit operations and the new auditing system events. For operations of type Object Access the access mask is also provided. The value of subfields for other translations should be obvious from the context of the operation. Table 1: full audit to LWIOD audit translation table full audit operation LWIOD audit event Access Mask (if applicable) brl cancel windows brl lock windows brl unlock windows chdir chflags Object Access Write Attributes chmod Object Access Change Permissions chmod acl Object Access Change Permissions chown Object Access Change Permissions close 1.2.4 Close closedir 1.2.2 Close connect 1.2.1 File Share create file 1.2.3 Open disconnect 1.2.1 Logoff disk free fchmod Object Access Change Permissions fchmod acl Object Access Change Permissions fchown Object Access Change Permissions fget nt acl Object Access Read Permissions fgetxattr Object Access Read Extended Attributes file id create flistxattr Object Access Read Extended Attributes fremovexattr Object Access Write Extended Attributes fs capabilities fset nt acl Object Access Change Permissions fsetxattr Object Access Write Extended Attributes fstat Object Access Read Attributes fsync ftruncate Object Access Write Data get alloc size Object Access Read Attributes get nt acl Object Access Read Permissions get quota get real filename Continued on next page 13

Table 1 continued from previous page full audit operation LWIOD audit event Access Mask (if applicable) get shadow copy data getlock getwd getxattr Object Access Read Extended Attributes init search op is offline kernel flock lchown Object Access Change Permissions lgetxattr link Object Access Write linux setlease listxattr Object Access Read Extended Attributes llistxattr Object Access Read Extended Attributes lock lremovexattr Object Access Write Extended Attributes lseek lsetxattr Object Access Write Extended Attributes lstat Object Access Read Attributes mkdir 1.2.6 Open mknod Open notify watch ntimes Object Access Write Attributes open Open opendir 1.2.2 Open pread Object Access Read Data pwrite Object Access Write Data read Object Access Read Data readdir Object Access List Folder readlink Object Access Read Data realpath recvfile Object Access Read Data removexattr Object Access Write Extended Attributes rename 1.2.5 Rename rename 1.2.5 Object Access Delete rewinddir rmdir 1.2.6 Object Delete seekdir sendfile Object Access Read Data set offline set quota setxattr Object Access Write Extended Attributes stat Object Access Read Attributes statvfs Object Access Read Attributes streaminfo Object Access Read Attributes strict lock strict unlock Continued on next page 14

Table 1 continued from previous page full audit operation LWIOD audit event Access Mask (if applicable) symlink Object Access Write telldir translate name unlink 1.2.6 Delete write Object Access Write Data 6 Differences between Windows Auditing and the new audit module One key difference between this new auditing system and Windows Auditing is the log format. For simplicity we will keep using syslog. The primary loss in data from syslog is the timestamp. The syslog timestamp does not include the year and is only precise to the second. Windows 2003 includes a year, and 2008 includes a microsecond timestamp. An advantage over the event log format is human readability. Windows Event logs are a binary format and can t be read with a standard text editor. The API for the new auditing system does not preclude logging in the event log format. Most, if not all, of the changes required to produce logs in the event log format could be made internal to the audit library. It should also be possible to write a script to convert the syslog logs to the event log format with minimal loss of data. There are other minor differences with the event log data. Windows implements logon failure as a separate event with more information about the failure. Open with delete on close is also a separate event. There is no way to directly tie a share level operation with a file level operation in the windows format. It is possible to infer which share a file was accessed through, but that information is not provided in the open event. There are also several events relating to modifications of the audit configuration that are not included in this implementation. 7 LWIOD Access Audit Module API 7.1 Global Enable configuration The global enable values will be stored at HKEY THIS MACHINE\Services\lwio\Parameters\Drivers\srv with the names AuditFileshareLevel and AuditLogonLevel. They will have the enum type. The values for the registry enum will be none, success, failure, and all. The new options will be defined in the SRV PROTOCOL CONFIG struct as follows: /* Enum Constants */ #define SRV_NUM_PROTOCOL_CONFIG_AUDIT_VALUES 4 static const PCSTR ppszsrvprotocolconfigauditenumnames[srv_num_protocol_config_audit_values] = { "all", "failure", "success", "none" }; 15

typedef enum { AUDIT_ALL = 0, AUDIT_FAILURE, AUDIT_SUCCESS, AUDIT_ } SRV_PROTOCOL_CONFIG_AUDIT_ENUM; typedef struct _SRV_PROTOCOL_CONFIG { BOOLEAN benablesmb2; BOOLEAN benablesigning; BOOLEAN brequiresigning; DWORD dwauditfilesharelevel; DWORD dwauditlogonlevel; ULONG ulzctreadthreshold; ULONG ulzctwritethreshold; } SRV_PROTOCOL_CONFIG, *PSRV_PROTOCOL_CONFIG; The entry in the python configuration script will be as follows: { "name": "audit-fileshare", "path": REGPATH_ONEFS_SRV_PARAMETERS, "key": "AuditFileshareLevel", "description": "Controls logging of fileshare audit event. The acceptable " "values are all, failure, success, and none", "cclass": CONFIG_CLASS_GLOBAL, "type": ENUM_TYPE, }, { "name": "audit-logon", "path": REGPATH_ONEFS_SRV_PARAMETERS, "key": "AuditLogonLevel", "description": "Controls logging of logon audit event. The acceptable " "values are all, failure, success, and none", "cclass": CONFIG_CLASS_GLOBAL, "type": ENUM_TYPE, } 7.2 Global SACL configuration The global sacl will be stored at HKEY THIS MACHINE\Services\lwio\Parameters\Drivers\onefs. It will have the name GlobalAuditSecurity and will be a binary blob. The data will be in the format of the SECURITY DESCRIPTOR RELATIVE type. The GlobalAuditSecuirty blob will be added to ONEFS CONFIG GLOBAL as follows: typedef struct _ONEFS_CONFIG_GLOBAL { BOOLEAN bdotsnapaccessiblechild; BOOLEAN bdotsnapaccessibleroot; BOOLEAN bdotsnapvisiblechild; BOOLEAN bdotsnapvisibleroot; 16

PSTR pszfakeglobalstring; PSTR *ppszfakeglobalmultistring; PSECURITY_DESCRIPTOR_ABSOLUTE pglobalauditsecurity; } ONEFS_CONFIG_GLOBAL, *PONEFS_CONFIG_GLOBAL; The python API is blocked by bug 66327. 7.3 libaudit 7.3.1 AuditAlarm() /** * Generate an Audit event * * @param[in] SessionId Session unique id. * @param[in] EventName Name of event. * @param[in] ClientToken Client security access token. * @param[in] EventResult Return value of function generating event. * @param[in] EventData Event specific portion of the log message. * @return STATUS_SUCCESS, otherwise appropriate error. */ NTSTATUS AuditAlarm( IN PVOID SessionId, IN PCSTR EventName, IN PACCESS_TOKEN ClientToken, IN NTSTATUS EventResult, IN PCSTR EventData ) 7.3.2 LogonAuditAlarm() /** * Generate a Logon Audit event * * @param[in] SessionId Session unique id. * @param[in] EventResult Return value of function generating event. * @param[in] LocalAddress Server IP address. * @param[in] RemoteAddress Client IP address. * @param[in] ClientPrincipalName Logon Username * @param[in] ClientToken Client security access token. * @param[in] AuditLogonLevel Logging disable bitmask: 1 success, 2 failure * @return STATUS_SUCCESS, otherwise appropriate error. */ NTSTATUS LogonAuditAlarm( IN PVOID SessionId, IN NTSTATUS EventResult, IN struct sockaddr* LocalAddress, IN struct sockaddr* RemoteAddress, IN PCSTR ClientPrincipalName, 17

IN PACCESS_TOKEN ClientToken, IN DWORD AuditLogonLevel ) 7.3.3 LogoffAuditAlarm() /** * Generate a Logoff Audit event * * @param[in] SessionId Session unique id. * @param[in] EventResult Return value of function generating event. * @param[in] ClientToken Client security access token. * @param[in] AuditLogonLevel Logging disable bitmask: 1 success, 2 failure * @return STATUS_SUCCESS, otherwise appropriate error. */ NTSTATUS LogoffAuditAlarm( IN PVOID SessionId, IN NTSTATUS EventResult, IN HANDLE ClientToken, IN DWORD AuditLogonLevel ) 7.3.4 FileshareAuditAlarm() /** * Generate a Fileshare Audit event * * @param[in] SessionId Session unique id. * @param[in] EventResult Return value of function generating event. * @param[in] ShareName Name of share. * @param[in] ClientToken Client security access token. * @param[in] GrantedAccess Access granted bitmask. * @param[in] AuditFileshareLevel Logging disable bitmask: 1 success, 2 failure * @return STATUS_SUCCESS, otherwise appropriate error. */ NTSTATUS FileshareAuditAlarm( IN PVOID SessionId, IN NTSTATUS EventResult, IN PCSTR ShareName, IN HANDLE ClientToken, IN DWORD GrantedAccess, IN DWORD AuditFileshareLevel ) 7.3.5 ObjectAuditAlarm() /** * Generate an Object Audit event * * @param[in] SessionId Session unique id. 18

* @param[in] EventName Name of event. * @param[in] EventResult Return value of function generating event. * @param[in] HandleId System unique handle to object. * @param[in] ClientToken Client security access token. * @param[in] EventData Event specific portion of the log message. * @return STATUS_SUCCESS, otherwise appropriate error. */ NTSTATUS ObjectAuditAlarm( IN PVOID SessionId, IN PCSTR EventName, IN NTSTATUS EventResult, IN PVOID HandleId, IN HANDLE ClientToken, IN PCSTR EventData ) 7.3.6 ObjectOpenAuditAlarm() /** * Generate an Object Open Audit event * * @param[in] SessionId Session unique id. * @param[in] EventResult Return value of function generating event. * @param[in] HandleId System unique handle to object. * @param[in] ShareName Name of share. * @param[in] ObjectTypeName Name of type of object. * @param[in] ObjectName Absolute path to object. * @param[in] psecuritydescriptor Pointer to security descriptor. * @param[in] ClientToken Client security access token. * @param[in] DesiredAccess Access requested bitmask. * @param[in] GrantedAccess Access granted bitmask. * @param[in] Operation Create Dispostion. * @param[out] AuditMaskSuccess Tracks Success Access Audit Alarms. * @param[out] AuditMaskFailure Tracks Failure Access Audit Alarms. * @param[out] GenerateAuditLog Enables Close, Rename, and Delete Audit Alarms. * @return STATUS_SUCCESS, otherwise appropriate error. */ NTSTATUS ObjectOpenAuditAlarm( IN PVOID SessionId, IN NTSTATUS EventResult, IN PVOID HandleId, IN PCSTR ShareName, IN PCSTR ObjectTypeName, IN PCSTR ObjectName, IN PSECURITY_DESCRIPTOR_ABSOLUTE psecuritydescriptor, IN HANDLE ClientToken, IN DWORD DesiredAccess, IN DWORD GrantedAccess, IN DWORD Operation, 19

OUT DWORD* AuditMaskSuccess, OUT DWORD* AuditMaskFailure, OUT PBOOL GenerateAuditLog ) 7.3.7 ObjectCloseAuditAlarm() /** * Generate an Object Close Audit event * * @param[in] SessionId Session unique id. * @param[in] EventResult Return value of function generating event. * @param[in] HandleId System unique handle to object. * @param[in] ClientToken Client security access token. * @param[in] GenerateAuditLog Enables logging. * @return STATUS_SUCCESS, otherwise appropriate error. */ NTSTATUS ObjectCloseAuditAlarm( IN PVOID SessionId, IN NTSTATUS EventResult, IN PVOID HandleId, IN HANDLE ClientToken, IN BOOL GenerateAuditLog ) 7.3.8 ObjectDeleteAuditAlarm() /** * Generate an Object Delete Audit event * * @param[in] SessionId Session unique id. * @param[in] EventResult Return value of function generating event. * @param[in] HandleId System unique handle to object. * @param[in] ClientToken Client security access token. * @param[in] GenerateAuditLog Enables logging. * @return STATUS_SUCCESS, otherwise appropriate error. */ NTSTATUS ObjectDeleteAuditAlarm( IN PVOID SessionId, IN NTSTATUS EventResult, IN PVOID HandleId, IN HANDLE ClientToken, IN BOOL GenerateAuditLog ) 7.3.9 ObjectAccessAuditAlarm() /** * Generate an Object Access Audit event * 20

* @param[in] SessionId Session unique id. * @param[in] EventResult Return value of function generating event. * @param[in] HandleId System unique handle to object. * @param[in] ClientToken Client security access token. * @param[in] DesiredAccess Access requested bitmask * @param[in,out] AuditMaskSuccess Tracks Success Access Audit Alarms. * @param[in,out] AuditMaskFailure Tracks Failure Access Audit Alarms. * @return STATUS_SUCCESS, otherwise appropriate error. */ NTSTATUS ObjectAccessAuditAlarm( IN PVOID SessionId, IN NTSTATUS EventResult, IN PVOID HandleId, IN HANDLE ClientToken, IN DWORD DesiredAccess, IN OUT DWORD* AuditMaskSuccess, IN OUT DWORD* AuditMaskFailure ) 7.3.10 ObjectRenameAuditAlarm() /** * Generate an Object Rename Audit event * * @param[in] SessionId Session unique id. * @param[in] EventResult Return value of function generating event. * @param[in] HandleId System unique handle to object. * @param[in] ObjectNewName Path to the new object. * @param[in] ClientToken Client security access token. * @param[in] GenerateAuditLog Enables logging. * @return STATUS_SUCCESS, otherwise appropriate error. */ NTSTATUS ObjectRenameAuditAlarm( IN PVOID SessionId, IN NTSTATUS EventResult, IN PVOID HandleId, IN PCSTR ObjectNewName, IN HANDLE ClientToken, IN BOOL GenerateAuditLog ) 21