The FDP_ITC requirement family of the Common Criteria says: """ The following events should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Successful import of user data, including any security attributes. b) Basic: All attempts to import user data, including any security attributes. c) Detailed: The specification of security attributes for imported user data supplied by an authorised user. """ The FDP_ITC requirement family of the Common Criteria says: """ The following events shall be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Successful export of information. b) Basic: All attempts to export information. """ These requirements are present in all the common protection profiles for operating systems (LSPP, CAPP). Fulfilling them in ssh means a very short code calling syslog() added to the scp and sftp, sftp-server source.
every read(2) and write(2) imports data, so you need to log this, too???
Logging read(2) and write(2) is the responsibility of the kernel. The kernel enhancements concerned with security (RSBAC, TrustedBSD et al) do that. I define Target of Evaluation (TOE) something like "the hardware, firmware, and software of a host, including some well-defined I/O devices: hard disk, chipcard reader, CD reader. The boundaries of TOE consist of its externel I/O interfaces such as network interface, printer port, chipcard reader, keyboard, display, mouse, USB interface to devices not defined as the part of the TOE, CD reader, etc. The proposed feature would log the exports/imports on the boundaries of the system, in our case export/imports on the network interface. Low (packet) level logging is also the responsibility of the kernel (packet filter code does that), so what remains is the import and export of files, with the file name, security attributes of the file (unix permissions) identity of the user, claimed identity of the user of the remote system if exists, and time (syslog takes care of the latter). An extra feature would be defining a generic interface returning the text representation of the security attributes of a file, and using that (if exists) to log the security attributes. (I mention it only for the sake of the record, first there should be some agreement on such an interface between the various security module developers.) int get_file_security_attributes_as_text(const char *fname, char *buffer, int buflen);
We don't have any plans to implement this. If someone comes up with patches, please discuss them on the openssh-unix-dev@mindrot.org list.
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.