From: Dan Raymond <draymond@foxvalley.net>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
Alan Coopersmith <alan.coopersmith@oracle.com>,
Rich Felker <dalias@libc.org>
Cc: libc-alpha@sourceware.org, libc-coord@lists.openwall.com
Subject: Re: [PATCH] fix calls to openlog() with LOG_KERN facility (Bug 3604)
Date: Tue, 6 Apr 2021 10:47:14 -0600 [thread overview]
Message-ID: <c1fee3cd-610c-35d7-61e7-f4ad017ec115@foxvalley.net> (raw)
In-Reply-To: <20210401152058.GH25400@brightrain.aerifal.cx>
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?
next prev parent reply other threads:[~2021-04-06 16:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-27 20:07 [PATCH] Bug 3604: fix calls to openlog() with LOG_KERN facility Dan Raymond
2021-03-31 15:19 ` Dan Raymond
2021-03-31 19:27 ` syslog and LOG_KERN - " Adhemerval Zanella
2021-03-31 19:44 ` [libc-coord] " Alan Coopersmith
2021-04-01 1:21 ` ***SPAM***Re: " Dan Raymond
2021-04-01 15:21 ` Rich Felker
2021-04-06 16:47 ` Dan Raymond [this message]
2021-04-09 17:37 ` Adhemerval Zanella
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c1fee3cd-610c-35d7-61e7-f4ad017ec115@foxvalley.net \
--to=draymond@foxvalley.net \
--cc=adhemerval.zanella@linaro.org \
--cc=alan.coopersmith@oracle.com \
--cc=dalias@libc.org \
--cc=libc-alpha@sourceware.org \
--cc=libc-coord@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).