Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 6 Apr 2021 10:47:14 -0600
From: Dan Raymond <>
To: Adhemerval Zanella <>,
 Alan Coopersmith <>, Rich Felker <>
Subject: Re: [PATCH] fix calls to openlog() with LOG_KERN facility (Bug 3604)

On 4/1/2021 9:21 AM, Rich Felker wrote:

> On 3/31/2021 7:21 PM, Dan Raymond wrote:
>> On 3/31/2021 1:44 PM, Alan Coopersmith wrote:
>>> On 3/31/21 12:27 PM, Adhemerval Zanella wrote:
>>>> Not allowing LOG_KERN by any user process seems to be de facto behavior
>>>> on all systems I am aware of:
>>>>    * FreeBSD and MUSL explicit set to previous log facility (they check
>>>>      if the priority against a mask and since on both LOG_KERN is 0 is
>>>>      set to the previous/default value).
>>>>    * Solaris 11.4 man page explicit says:
>>>>         LOG_KERN      Messages generated by the kernel. These cannot be  gener-
>>>>                       ated by any user processes.
>>>>    * AIX 7.2 is similar, but it seems to provide a special symbol for that
>>>>      (which seems to not have a man page):
>>>>         LOG_KERN      Logs messages generated by the kernel. Kernel processes
>>>>                       should use the bsdlog routine to generate syslog messages.
>>>>                       The syntax of bsdlog is identical to syslog. The bsdlog
>>>>                       messages can only be created by kernel processes and must
>>>>                       be of LOG_KERN priority. The syslog subroutine cannot log
>>>>                       LOG_KERN facility messages. Instead it will log LOG_USER
>>>>                       facility messages.
>>>> So before to make glibc an outlier here to fix a very specific issue, I
>>>> would like to check with other implementation the possible security
>>>> implication and whether it make sense to change it.
>>> The Solaris implementation is similar to FreeBSD & MUSL - LOG_KERN 
>>> is 0,
>>> so appears the same to syslog() as not specifying a facility and 
>>> letting
>>> the default value be used. 
>> It's a fair point that even with this patch the user can't explicitly 
>> specify LOG_KERN during a call to syslog().  To use LOG_KERN they 
>> must call openlog() first and set it as the default facility.  That's 
>> a little clumsy but it is good enough to fix the klogd implementation 
>> in busybox.  What is the alternative?  To rewrite klogd so it 
>> bypasses syslog() altogether and writes directly to the syslogd 
>> socket?  That seems inefficient and doesn't really achieve any 
>> security.  If klogd can do this any user process can do it too.
> It's not a matter of security (this is not a security boundary) but of
> interface contract:
>      "Values of the priority argument are formed by OR'ing together a
>      severity-level value and an optional facility value. If no
>      facility value is specified, the current default facility value is
>      used."
> However:
> It looks like the proposed patch is not making syslog violate its
> interface contract, only fixing glibc's existing violation of the
> openlog interface contract where it's ignoring the facility argument
> when the value is zero. If my understanding is correct, that would
> just bring glibc in line with what musl already does, not make it an
> outlier.
> Admittedly having to use openlog to set LOG_KERN is hideous because it
> involves global state and might break other code in the same process,
> but at least it works and it's probably acceptable for the rare
> application that has legitimate reason to send LOG_KERN messages
> (klogd/syslogd only?).
> Another possible solution on the libc side would be redefining
> LOG_KERN to something nonzero and remapping it to the value 0 on the
> wire. But I suspect this would break syslogd implementations.

Adhemerval, have you had a chance to look into this?

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.