From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by sourceware.org (Postfix) with SMTP id 3D979385800F for ; Tue, 6 Apr 2021 16:48:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3D979385800F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foxvalley.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=draymond@foxvalley.net Received: (qmail 12568 invoked from network) for libc-alpha@sourceware.org; 6 Apr 2021 11:48:44 -0500 Received: from unknown (HELO ?192.168.1.3?) (draymond@161.97.241.227) by mail.foxvalley.net with SMTP; 6 Apr 2021 11:48:44 -0500 Subject: Re: [PATCH] fix calls to openlog() with LOG_KERN facility (Bug 3604) To: Adhemerval Zanella , Alan Coopersmith , Rich Felker Cc: libc-alpha@sourceware.org, libc-coord@lists.openwall.com References: <1395b5b8-0fc7-ae01-c8e1-5e13f3a4394c@foxvalley.net> <86d18b12-c12b-9837-de7a-9dcb377ed6c4@linaro.org> <20210401152058.GH25400@brightrain.aerifal.cx> From: Dan Raymond Message-ID: Date: Tue, 6 Apr 2021 10:47:14 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210401152058.GH25400@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 16:48:47 -0000 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?