From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12987 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: arc4random/csprng Date: Wed, 4 Jul 2018 11:13:03 -0400 Message-ID: <20180704151303.GR1392@brightrain.aerifal.cx> References: <20180702203957.GA9081@brightrain.aerifal.cx> <647a7190-b70b-23a2-9b3c-a24b44fcac99@redhat.com> <20180703144714.GM1392@brightrain.aerifal.cx> <5d28fcf7-b869-175d-c2b7-9c61ef1d40cd@redhat.com> <20180703151756.GO1392@brightrain.aerifal.cx> <04c54490-5d2f-0690-cbca-96326b0e338e@redhat.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1530717078 12130 195.159.176.226 (4 Jul 2018 15:11:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2018 15:11:18 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Florian Weimer Original-X-From: musl-return-13003-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 04 17:11:14 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fajR1-00031h-Hu for gllmg-musl@m.gmane.org; Wed, 04 Jul 2018 17:11:11 +0200 Original-Received: (qmail 7880 invoked by uid 550); 4 Jul 2018 15:13:19 -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 7853 invoked from network); 4 Jul 2018 15:13:18 -0000 Content-Disposition: inline In-Reply-To: <04c54490-5d2f-0690-cbca-96326b0e338e@redhat.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12987 Archived-At: On Wed, Jul 04, 2018 at 01:36:00PM +0200, Florian Weimer wrote: > On 07/03/2018 05:17 PM, Rich Felker wrote: > > >>But it's still quite common to do things with direct system calls, > >>particularly for setting up containers. > >> > >>I have not yet found a case which I couldn't solve with plain fork > >>(with handlers) and unshare, but that's not what everyone does > >>unfortunately. > > > >I agree you might need direct use of clone sometime for > >namespace/container stuff, but I don't think there's any way it can be > >made safe without careful consideration of what you do after the > >operation before a subsequent execve or _exit. I don't think it makes > >sense to design big machinery to support doing something that has > >deeper reasons it can't work, but this is probably partly a difference > >in philosophy between glibc and musl (see also: dlclose, lazy dtls, > >lazy tlsdesc, ...). > > I would suggest to keep at least the fork detection bit, even if you > do not reseed and deadlock or abort instead, because the duplicate > stream of random bits could be very hard to detect otherwise. I don't want, and I don't think others will want, musl to be unconditionally mmapping extra memory in every process for the sake of safely handling programs doing invalid/unsupported hacks. What might be acceptable is something like, at stirring time, doing: if (__syscall(SYS_gettid)!=self->tid) a_crash(); Another idea is adding to syscall.c (public syscall() function) something like: if (n==SYS_fork || n==SYS_clone) flag=1; and in the csprng: if (flag) a_crash(); or just: if (n==SYS_fork || n==SYS_clone) return __syscall_ret(-EINVAL); In any case, the public clone() function, which should be valid to use in a limited sense if we're offering it at all, should also be reviewed for safety (not specific to csprng issues) and for what properties we want to guarantee/support, like whether it's valid to do non-AS-safe stuff after a fork-like clone in a single-threaded process. The above flag idea may be a useful tool in this -- by actively storing knowledge that a type of fork/clone that leaves the process in an async signal context has taken place, we could trap a lot of UB in the child. Rich