From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7319 Path: news.gmane.org!not-for-mail From: u-wsnj@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817 Date: Thu, 2 Apr 2015 20:36:27 +0200 Message-ID: <20150402183627.GE4456@example.net> References: <20150330053150.GA484@brightrain.aerifal.cx> <20150331234810.GN6817@brightrain.aerifal.cx> <20150401074116.GN23636@example.net> <551BA847.3040609@gmx.de> <20150401084940.GO23636@example.net> <551D4A74.7070102@gmx.de> <20150403002656.11f75341@r2lynx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1427999828 3436 80.91.229.3 (2 Apr 2015 18:37:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Apr 2015 18:37:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7332-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 02 20:37:08 2015 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 1Ydjz8-0004A4-Nk for gllmg-musl@m.gmane.org; Thu, 02 Apr 2015 20:36:58 +0200 Original-Received: (qmail 13900 invoked by uid 550); 2 Apr 2015 18:36:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13882 invoked from network); 2 Apr 2015 18:36:56 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe09.swip.net; client-ip=78.108.63.46; envelope-from=u-wsnj@aetey.se Content-Disposition: inline In-Reply-To: <20150403002656.11f75341@r2lynx> Xref: news.gmane.org gmane.linux.lib.musl.general:7319 Archived-At: On Fri, Apr 03, 2015 at 12:26:56AM +0700, Рысь wrote: [Harald Becker wrote] > > This would be a very simple change in the kernel, giving a big step > > to more security ... but still such things are missing :( [answering to Harald Becker] Credentials handling in the kernel is a result of a very long evolution and efforts for making the behaviour both relatively consistent and conforming to its documented standard definition. If you believe that such a change can be simple and easily contained in scope, you fall for wishful thinking. Unix is monolithic by design, it is extremely hard to improve without throwing out its design or otherwise hitting lots of issues in very different places where you inadvertently would break someone else's assumptions. Linux did not throw out the design and thus had to preserve lots of problems and limitations, for a reason. On Fri, Apr 03, 2015 at 12:26:56AM +0700, Рысь wrote: > Audit your filesystem and remove all > setuid bits from all programs, move/rename them as prog.real and place > a shell script in place which will call setuid wrapper which then will > setreuid(uid, 0) then execve(). This way you are still exposed to setuid and also still depend on how the prog.real is going to use the supplied credentials. You more or less have to reimplement in your wrapper the checks expected "to be already present" in the program, without any control over its internals. This can certainly improve the situation if you are (which presumably is the case) more security-oriented and thoughtful than the upstream developer, but you are in an uphill battle. For me this does not look like a solution, rather like a patchwork which may or may not be effective. Rune