From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9306 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: list of security features in musl Date: Thu, 11 Feb 2016 03:41:05 -0500 Message-ID: <20160211084105.GL9349@brightrain.aerifal.cx> References: <20160211085613.2e58f751@ncopa-desktop.alpinelinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1455180083 9630 80.91.229.3 (11 Feb 2016 08:41:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Feb 2016 08:41:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9319-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 11 09:41:23 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aTmoT-0000fD-Bl for gllmg-musl@m.gmane.org; Thu, 11 Feb 2016 09:41:21 +0100 Original-Received: (qmail 30467 invoked by uid 550); 11 Feb 2016 08:41:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 30449 invoked from network); 11 Feb 2016 08:41:18 -0000 Content-Disposition: inline In-Reply-To: <20160211085613.2e58f751@ncopa-desktop.alpinelinux.org> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9306 Archived-At: On Thu, Feb 11, 2016 at 08:56:13AM +0100, Natanael Copa wrote: > Hi, > > Once in a while I get question about what security features there are > in musl. Are there such list some where? Some are briefly mentioned in the libc comparison: http://www.etalabs.net/compare_libcs.html but it's not very complete in this area. The things I would really call security _features_ in musl are: - Stack protector, with failure handling that rapidly terminates the process rather than continuing along error-reporting code paths which can themselves provide an attack surface. - Double-free protection (to the extent possible), with the same rapid termination. - Moderate level heap overflow protection - checking for clobbered heap chunk footers on realloc and free, also with rapid termination. - Ability to build libc itself with stack protector enabled, to catch libc-internal stack smashing. - Password hashing with bcrypt. - Ability to use PIE together with static linking (load static-linked program at randomized address). - Blocking all LD_* for suid/sgid binaries, not just partially restricting what they can do. - Translatable text in libc is purely literal strings, no format strings, so buggy or malicious translations are not a format string attack vector. In addition, the following design concepts/practices contribute to security: - Simplicity/reviewability of code ("The main security feature is that you can read the code" - nsz). - Non-use of arbitrary-size VLA/alloca, minimal dynamic allocation. - Attention to subtle race condition and async-signal safety issues, as demonstrated by the extensive list of such bugs found in glibc by musl developers. - Aim to avoid/remove all undefined behavior even when it's not yet dangerous with current compiler technology. - Safe, fully-standards-conforming handling of UTF-8. - Producing consistent results even under transient errors (failure to obtain a file/resource does not cause silent fallback to defaults that may be wrong). - No late/lazy allocation that would require aborting the program if it fails. There are probably more interesting points for security, but I think I covered the most important ones. If I missed any, reply with additions. Rich