PERFORCE change 92365 for review

[Christian S.J. Peron]

Robert Watson wrote:

>
> On Sat, 25 Feb 2006, Christian S.J. Peron wrote:
>
>>> @@ -795,7 +795,11 @@
>>>         }
>>>     }
>>>
>>> +#ifdef LOG_SECURITY
>>>     openlog("auditd", LOG_CONS | LOG_PID, LOG_SECURITY);
>>> +#else
>>> +    openlog("auditd", LOG_CONS | LOG_PID, LOG_AUTH);
>>> +#endif
>>>     syslog(LOG_INFO, "starting...\n");
>>>
>>>     if (debug == 0 && daemon(0, 0) == -1) {
>>
>>
>> In userspace, we are using LOG_AUTH | LOG_ERR to report audit 
>> failures, at least for login(1) and su(1). Might be a good idea to be 
>> consistent, anyway.
>
>
> My general feeling has been that audit-related log material shouldn't 
> go into publically readable logs.  LOG_SECURITY works well for this on 
> FreeBSD; however, LOG_AUTHPRIV is probably the better place for the 
> log messages to go so that they don't enter a world-readable log file 
> on other systems?  This looks like it will work on Linux and Darwin.  
> On Solaris, there's a LOG_AUDIT, which has the same underlying numeric 
> value as LOG_SECURITY on FreeBSD.
>
> Robert N M Watson
>
>
I would agree here. I just consulted RFC 3164 to see if there is 
anything that they are designating for security related messages and 
here is what I found:

       Numerical             Facility
          Code

           0             kernel messages
           1             user-level messages
           2             mail system
           3             system daemons
           4             security/authorization messages (note 1)
           5             messages generated internally by syslogd
           6             line printer subsystem
           7             network news subsystem
           8             UUCP subsystem
           9             clock daemon (note 2)
          10             security/authorization messages (note 1)
          11             FTP daemon
          12             NTP subsystem
          13             log audit (note 1)
          14             log alert (note 1)
          15             clock daemon (note 2)
          16             local use 0  (local0)
          17             local use 1  (local1)
          18             local use 2  (local2)
          19             local use 3  (local3)
          20             local use 4  (local4)
          21             local use 5  (local5)
          22             local use 6  (local6)
          23             local use 7  (local7)

        Note 1 - Various operating systems have been found to utilize
           Facilities 4, 10, 13 and 14 for security/authorization,
           audit, and alert messages which seem to be similar.


-- 
Christian S.J. Peron
csjp at FreeBSD.ORG
FreeBSD Committer
FreeBSD Security Team