[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c1fee3cd-610c-35d7-61e7-f4ad017ec115@foxvalley.net>
Date: Tue, 6 Apr 2021 10:47:14 -0600
From: Dan Raymond <draymond@...valley.net>
To: Adhemerval Zanella <adhemerval.zanella@...aro.org>,
Alan Coopersmith <alan.coopersmith@...cle.com>, Rich Felker <dalias@...c.org>
Cc: libc-alpha@...rceware.org, libc-coord@...ts.openwall.com
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.
