PSARC Questions Version 4.5 ------------------------------------------------------------------------ 1. What specifically is the proposal that we are reviewing? - What is the technical content of the project? The project introduces a new (project private) interface between the kernel module c2audit and the daemon auditd. With the current interface, auditd passes to the kernel module c2audit a file handle to which c2audit writes audit data. With this interface, auditd does no processing of the data. The new interface operates in parallel to the old; auditd now optionally passes a door handle to c2audit which acts as a door client. ("parallel" in this case means that auditd may pass one or both file handle types on separate threads and expect output on each.) auditd gains a new role as a door server, receiving binary audit data and passing it to a plugin. The supplied plugin does optional filtering of records and extracts fields from each audit record to be output via syslog(3C) to a syslog daemon. The syslog messages are standard syslog records consisting of a header and a message; the message is intended to be human readable. There are no new public interfaces - Is this a new product, or a change to a pre-existing one? If it is a change, would you consider it a "major", "minor", or "micro" change (see the Release Taxonomy in http://sac.eng.sun.com/doc/release.taxonomy)?] This is a new feature for the existing Solaris audit and completely preserves the existing functions, interfaces, and data formats. The customer must modify audit configuration files to see the new function. It is a micro/patch release. - If your project is an evolution of a previous project, what changed from one version to another? n.a. - What is the motivation for it, in general as well as specific terms? (Note that not everyone on the ARC will be an expert in the area.) The primary reason for this project is that audit data be stored separately from where it is generated; a root compromise of an audited machine does not give an attacker the ability to delete or modify the audit log. The secondary reason is to respond to customer requests that audit data be available in syslog form. - What are the expected benefits for Sun? Increased use of Solaris audit. - By what criteria will you judge its success? Test results showing equivalent records in syslog and the binary audit log and correct filtering based on the plugin: directive in /etc/security/audit_control. 2. Describe how your project changes the user experience, upon installation and during normal operation. - What does the user perceive when the system is upgraded from a previous release? Nothing. After configuring audit to generate syslog output and configuring a syslog server to store syslog messages of type "audit", the customer will see audit records in syslog format. 3. What is its plan? - What is its current status? Has a design review been done? Are there multiple delivery phases? Single delivery phase; design review was held in December, 2002. There are future (uncommitted) plans proposed for reliability and communications security, but the completing these plans does not affect the usefulness of this project. 4. Are there related projects in Sun? No. 5. How is the project delivered into the system? - Identify packages, directories, libraries, databases, etc. One new library is created; it is a replaceable plugin to auditd which implements the binary to syslog format translation and the output of syslog records. It will be packaged with the existing audit files in SUNWcsu and will | be installed to /usr/lib/security/audit_syslog.so. A new header file for this library's interface is /usr/include/security/auditd.h. All other deliverables are to existing binaries, man pages and configuration files. 6. Describe the project's hardware platform dependencies. none. 7. System administration - How will the project's deliverables be installed and (re)configured? No reconfiguration is required. Installation via pkgadd is a straight forward replacement of binaries and man pages plus the addition of the new plugin library. - How will the project's deliverables be uninstalled? Part of the core system; cannot be uninstalled. - Does it use inetd to start itself? no - Does it need installation within any global system tables? no. (Note that audit is enabled via an entry in /etc/system; no change to this mechanism is planned.) - Does it use a naming service such as NIS, NIS+ or LDAP? no (Note that audit defines the content of /etc/security/audit_user via nsswitch for the above. No change to this mechanism is planned.) - What are its on-going maintenance requirements (e.g. Keeping global tables up to date, trimming files)? The syslog file is managed via logadm. The current handling of binary audit files is unchanged. - How does this project's administrative mechanisms fit into Sun's system administration strategies? E.g., how does it fit under the Solaris Management Console (SMC) and Web-Based Enterprise Management (WBEM), how does it make use of roles, authorizations and rights profiles? Additionally, how does it provide for administrative audit in support of the Solaris audit configuration? It does not. A separate project is on the list of projects for the Hardened Solaris program to provide adminstration for audit, which currently has no administration instrumentation or GUI. - What tunable parameters are exported? Can they be changed without rebooting the system? Examples include, but are not limited to, entries in /etc/system and ndd(8) parameters. What ranges are appropriate for each tunable? What are the commitment levels associated with each tunable (these are interfaces)? Lines in syslog.conf and audit_control initiate the new function. syslog.conf is re-read by sending syslogd SIGHUP and audit_control is re-read by the command line "audit -s." 8. Reliability, Availability, Serviceability (RAS) - Does the project make any material improvement to RAS? no. - How can users/administrators diagnose failures or determine operational state? (For example, how could a user tell the difference between a failure and very slow performance?) On the syslog server, tail -f the configured syslog file. (with much traffic, "ls -l" done twice is sufficient.) In low traffic, perform an auditable operation (such as login) and verify that the syslog file is updated. Failure with UDP does not generally result in poor performance but in lost data. - What are the project's effects on boot time requirements? auditd is not started by default. If audit is configured but the new feature is not enabled, there is no change in boot time. The new feature, if configured, adds less than 300ms to the auditd boot. - How does the project handle dynamic reconfiguration (DR) events? n.a. - What mechanisms are provided for continuous availability of service? Availability of audit record output depends on auditd's running. The effect of losing auditd on the system depends on audit configuration; the default is that the audit data will be discarded. An audit policy can be configured via /etc/security/audit_startup(1M) that will cause audited processes to block until data space is made available. The new feature makes no change to these mechanism. In the syslog mode there is no backpressure and therefore no blocking. - Does the project call panic()? Explain why these panics cannot be avoided. This project adds no calls to panic. - How are significant administrative or error conditions transmitted? SNMP traps? Email notification? The primary mechanism is via the script /etc/security/audit_warn, which can be modified by the customer to achieve various alerts, including e-mail. The secondary mechanism is syslog. - How does the project deal with failure and recovery? Failures due to data and configuration inputs are handled as described above -- output a warning, drop the offending operation, continue. File system full is handled by the existing product by use of multiple partitions. - Does it ever require reboot? If so, explain why this situation cannot be avoided. No change from existing Solaris audit. - How does your project deal with network failures (including partition and re-integration)? How do you handle the failure of hardware that your project depends on? For UDP, the types of failure that are detectable are few. In the case of failure in a syslog-only configuration, the audit policy of block/no block is used, however if both syslog output and file output are selected by configuration at one time, the file output will continue without interuption and the only indication of the failure will be e-mail notification via audit_warn. However, due to certification requirements, file full conditions will continue to block processes (depending on policy) even it the syslog mechanism appears to be working. - Can it save/restore or checkpoint and recover? No. A system panic results in the loss of queued but not output audit records. - Can its files be corrupted by failures? Does it clean up any locks/files after crashes? In a crash, the last record of a binary audit log may be incomplete; the existing audit utitilities can read all the completed records without loss. The new feature depends on the operation of syslogd and makes no change to its design and implementation. Syslog keeps malformed data by generating a valid header when an invalid header is detected. 9. Observability - Does the project export status, either via observable output (e.g., netstat) or via internal data structures (kstats)? No change to Solaris audit. - How would a user or administrator tell that this subsystem is or is not behaving as anticipated? Direct observation of the log files. - What statistics does the subsystem export, and by what mechanism? The "auditconfig -getstat" command reports statistics kept concerning the queuing and broad classes of audit record types. No new statistics are kept for the new function. - What state information is logged? none. - In principle, would it be possible for a program to tune the activity of your project? The thread design in auditd for translation of binary records to syslog and for syslog output depends on hard coded resource limits such as the maximum number of translation threads. In principle, these could be made configurable. 10. What are the security implications of this project? - What security issues do you address in your project? Solaris audit collects data about use of privilege -- who did what operation to which object and whether the operation sucessful. This information can be used to determine if legitimate users are misusing the system or if non-legitimate (in some cases illegitimate, but that's not relevant) users are misusing the system. The later case is generally what is used for intrusion detection and (after the fact) analysis. The problem is that once an attacker has compromised the system, the audit logs are easily deleted. A sophisticated attacker could write garbage to the log to hide the fact that data has been intentionally destroyed or modify the log to hide evidence. With the syslog function, the data is on a remote machine which must be separately compromised before audit data can be destroyed or altered. - The Solaris audit configuration carries a Common Criteria (CC) Controlled Access Protection Profile (CAPP) -- Orange Book C2 -- and a Role Based Access Control Protection Profile (RBAC) -- rating, does the addition of your project effect this rating? E.g., does it introduce interfaces that make access or privilege decisions that are not audited, does it introduce removable media support that is not managed by the allocate subsystem, does it provide administration mechanisms that are not audited? No. - Is system or subsystem security compromised in any way if your project's configuration files are corrupt or missing? Yes. Audit depends on valid configuration files in /etc/security. This project does not change this dependency. - Please justify the introduction of any (all) new setuid executables. 11. What is its UNIX operational environment: - Which Solaris release(s) does it run on? Solaris 10. - Environment variables? Exit status? Signals issued? None. Signals caught? (See signal(3HEAD).) Auditd presently catches SIGHUP, SIGTERM, SIGALRM, and SIGUSR1. No change in the use or semantics of these signals are necessary for the new function. - Device drivers directly used (e.g. /dev/audio)? .rc/defaults or other resource/configuration files or databases? no. - Does it use any "hidden" (filename begins with ".") or temp files? no. - Does it use any locking files? no. - Command line or calling syntax: What options are supported? (please include man pages if available) Does it conform to getopt() parsing requirements? See the man pages. Yes, getopt() requirements are met. - Is there support for standard forms, e.g. "-display" for X programs? Are these propagated to sub-environments? n.a. - What shared libraries does it use? (Hint: if you have code use "ldd" and "dump -Lv")? libbsm.so, libnsl.so, librt.so, libpthread.so, libdoor.so, libsocket.so, libc.so, libmd5.so, libdl.so, libmp.so, liaio.so, libthread.so. The new function adds the door and thread libraries to those loaded by auditd. - Identify and justify the requirement for any static libraries. none. - Does it depend on kernel features not provided in your packages and not in the default kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional kernel loadable modules)? No. - Is your project 64-bit clean/ready? If not, are there any architectural reasons why it would not work in a 64-bit environment? Does it interoperate with 64-bit versions? Yes (clean, interoperable). - Does the project depend on particular versions of supporting software (especially Java virtual machines)? If so, do you deliver a private copy? What happens if a conflicting or incompatible version is already or subsequently installed on the system? No. - Is the project internationalized and localized? Yes. - Is the project compatible with IPV6 interfaces and addresses? Yes. 12. What is its window/desktop operational environment? None. 13. What interfaces does your project import and export? - Please provide a table of imported and exported interfaces, including stability levels. Pay close attention to the classification of these interfaces in the Interface Taxonomy (e.g. "Standard", "Stable", "Evolving", etc.; see the interface taxonomy document in http://sac.eng.sun.com/doc/interface.taxonomy). Use the following format: Interfaces Imported Interface Classification Comments |audit_plugin Contracted Project imported by audit_syslog.so Private Defined in new (Contracted Project Private) audit_plugin(3BSM) man page provided with the commitment materials. Interfaces Exported Interface Classification Comments auditsvc Project private Interface between auditd and c2audit; previously "stable." See PSARC 2002/665 audit_plugin Contracted Project Private See audit_plugin man page provided with the commitment materials. |audit_syslog.so Unstable file format syslog message format Unstable file content syslog.conf "audit" facility code - Exported public library APIs and ABIs Protocols (public or private) Drag and Drop ToolTalk Cut/Paste none. - Other interfaces syslog protocol meets RFC 3164. (The Solaris implementation was considered in this after-the-fact specification.) - What other applications should it interoperate with? How will it do so? syslogd via syslog(3C) - Is it "pipeable"? How does it use stdin, stdout, stderr? n.a. - Explain the significant file formats, names, syntax, and semantics. See RFC 3164. There is a standard header after which the solaris implementation adds an [ID nnnn some.text] field, followed by a "message" which has as its only limitations that it be 7bit characters and the total record length <= 1024. For this project, the message format is described in the specification included as part of the project materials. - Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? no. - Are the externally visible interfaces documented clearly enough for a non-Sun client to use them successfully? Yes. audit_log(4) and the new audit_syslog(5) man pages document the output and plugin library. The new plugin API is Contracted Project Private. 14. What are its other significant internal interfaces inter-subsystem and inter-invocation)? - Protocols (public or private) see syslog, above. - Private ToolTalk usage none. - Files syslog file is "standard" binary audit logs are evolving format and unstable content. - Other - Are the interfaces re-entrant? The auditsvc interface is re-entrant; it is called from one or two threads of auditd to get file and syslog output. It enforces a limit of one file call and one door (syslog output) call; calls over that limit do not affect current operations on the interface. 15. Is the interface extensible? How will the interface evolve? - How is versioning handled? The auditsvc() system call is not versioned and the syslog protocol does not provide for version information. The existing binary log includes a version number which is used by the audit utilities to provide upward compatibility. - What was the commitment level of the previous version? auditsvc() is private as of Solaris 10. The file formats were evolving and the file contents unstable. There is no previous version for the plugin API. - Can this version co-exist with existing standards and with earlier and later versions or with alternative implementations (perhaps by other vendors)? Yes -- existing third party products which replace auditd will continue to be able to use auditsvc for file output. However the use of the plugin library makes unnecessary the replacing of auditd and the use of auditsvc. - What are the clients over which a change should be managed? The change is only to clients; the server is syslogd, which is unchanged. To bring up the new function, syslogd should first be configured for the new AUDIT syslog "facility" and then the clients configured for the syslogd hostname. - How is transition to a new version to be accomplished? What are the consequences to ISV's and their customers? See previous. 16. How do the interfaces adapt to a changing world? - What is its relationship with (or difficulties with) multimedia? 3D desktops? Nomadic computers? Storage-less clients? A networked file system model (i.e., a network-wide file manager)? n.a. 17. Interoperability - If applicable, explain your project's interoperability with the other major implementations in the industry. In particular, does it interoperate with Microsoft's implementation, if one exists? The new function provides interoperability with products which use syslogd as a central logging mechanism. Many of the existing "network log" products operate on Microsoft hosts. - What would be different about installing your project in a heterogeneous site instead of a homogeneous one (such as Sun)? none. - Does your project assume that a Solaris-based system must be in control of the primary administrative node? n.a. 18. Performance - How will the project contribute (positively or negatively) to "system load" and "perceived performance"? Different audit configurations result in wildly different rates of audit record generation; in the environment for which syslog output is envisioned, the rate should be low. There are no added performance costs for when the function is not enabled. - What are the performance goals of the project? How were they evaluated? What is the test or reference platform? Meet boottime requirements -- no increase in auditd start up for when the feature is not enabled. - Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? no. However, see failure modes, question 8 for the audit policy concerning blocking. - What is your project's MT model? How does it use threads internally? How does it expect its client to use threads? If it uses callbacks, can the called entity create a thread and recursively call back? No callbacks, no thread issues for clients. - What is the impact on overall system performance? What is the average working set of this component? How much of this is shared/sharable by other apps? No formal performance measurements have been done on audit. It is believed that turning audit on causes measureable degradation even if records are not generated. It is possible to configure auditing so that it can significantly impact performance. This project makes no significant changes to this status except that if both binary and syslog output are selected, performance will be further reduced. Selecting either but not both will result in unchanged performance. - Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? No. - Will it require large files/databases (for example, new fonts)? The syslog file growth is unbounded. This is controlled by cron and logadm. - Do files, databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? File growth does not affect performance; logadm provides the file management. 19. Please identify any issues that you would like the ARC to address. Should the Contracted Project Private plugin header file be delivered or go to proto only? 20. Appendices to include - One-Pager. See http://nishiki.eng/projects/audit/secureLog/obsolete/onepager1.txt Not included in the case materials since it is now obsolete. - Prototype specification. See case directory or http://nishiki.eng/projects/audit/secureLog/specification1.html - References to other documents. (Place copies in case directory.) man page diffs for audit_control, auditreduce, audit_class, and auditd have been placed in the case directory. Notes for the writer of the Administration manual chapter on auditing are also in the case directory. RFC 3164, BSD syslog