From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7310 Path: news.gmane.org!not-for-mail From: Harald Becker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817 Date: Thu, 02 Apr 2015 15:56:04 +0200 Message-ID: <551D4A74.7070102@gmx.de> References: <20150330053150.GA484@brightrain.aerifal.cx> <20150331234810.GN6817@brightrain.aerifal.cx> <20150401074116.GN23636@example.net> <551BA847.3040609@gmx.de> <20150401084940.GO23636@example.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1427982994 31935 80.91.229.3 (2 Apr 2015 13:56:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Apr 2015 13:56:34 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7323-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 02 15:56:23 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 1YdfbZ-0005xJ-02 for gllmg-musl@m.gmane.org; Thu, 02 Apr 2015 15:56:21 +0200 Original-Received: (qmail 3101 invoked by uid 550); 2 Apr 2015 13:56:19 -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 3080 invoked from network); 2 Apr 2015 13:56:18 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: <20150401084940.GO23636@example.net> X-Provags-ID: V03:K0:ZsGQom6xmeWH8LcWY2XbqilOLUSRvTUxcLfwpPEgZZXWefeqaEk quBWDomsEjQYQQF7TNPJ7mMF7d4z2XdVs3T0d94+SRM/3w6fhi1iaGkp+HGeOeLDVmvK3bt JY5dWBE00TOKgWr5dyfu9afosJ1D+JaNQDRghWHbSJQNv6ekZLtreMjiyBQcUgbpW3+oEUY gyKXRpNISa7H9k+ZjX3yw== X-UI-Out-Filterresults: notjunk:1; Xref: news.gmane.org gmane.linux.lib.musl.general:7310 Archived-At: Hi ! On 01.04.2015 10:49, u-wsnj@aetey.se wrote: > Note that root does not need suid to drop its privileges. Yes, but may benefit from the simplicity to do the drop: Consider a suid program to a low privileged user, whenever that program is called from any root process, the called program automatically drops it's privileges. So you do not need to drop privileges in every possible caller. >> privileges of a different user (may be allowing access to some >> files only by using specific commands). > > As soon as a program is setuid it has to be written for the purpose > of very reliably checking and limiting what it does on behalf of > who, independently of how it can potentially be invoked "out of > context". ACK. Any program going to be used with suid, or sgid has to be designed for this. > This is known to be hard, I believe it is harder to do reliably than > e.g. issue a request to a daemon - talking about the complexity > level. Hard? A single getuid() call gives the user id of the calling user (real user id), where the program runns with the priviledges of the effective user (geteuid). So you can pick the real user id and check this against a list of allowed users; same to getgid(). In addition: suid programs should set the owning group and permisions carefully, e.g. fileuser:accessgroup owner=suid+x, group=x, other=none; where the directories and files are owned by fileuser, with permissions only to that user and nobody else. A simple mechanism giving you a shield protecting your data from being tampered by any other users programs (except root), but still all users which are a member of group accessgroup can use your program, and access the data in the intended manner. > Thus the setuid program is to be designed to be as small as > possible, presumably leaving all non-checking functions to (a) > different executable(s). True, for suid *root* programs, but otherwise I doubt. I see no such need in e.g. the example above. > Then the result becomes about as intricate as talking to a daemon, > which can be run without any setuid. I never told talking to a daemon is of no use, but many suid usages are possible without the daemon overhead, and still not risking security violations. The big flaws are: a) setting suid for a program never designed for that use b) suid *root* (flaw by design) IMO the case b should be blocked by the kernel and replaced with a more reliable reaction: Whenever the kernel detects a suid *root* program, it does not start that program, but picks a configured path, for a statically linked binary, with owner root, only executable by root, and no permissions to others. That program shall be started by the kernel, giving the path to the called program as first argument, then the remaining arguments. This single *real suid root* program get than control (single point of failure), and has to do the security relevant part (as you mentioned above). Only when there is no doubt of usage, this single program drops the privileges to the determined / required user, and then exec to the intended program. In other words, any program marked suid root is automatically invoked through a program like sudo, which does the security checking, before invoking any other code ... but without need of manually reentering that sudo command on every program invocation. This would be a very simple change in the kernel, giving a big step to more security ... but still such things are missing :( >> When used with care and as intended, suid and sgid is a nice >> feature, but > > Unfortunately I can not really appreciate its beauty which appears to > hide the complexity and/or move it to other parties (like the dynamic > linker or the software maintenance infrastructure). Yes it "looks > simple and efficient" but is it, really? Not talking about suid *root*, which difficulties do you see? It's beauty lies in it's simplicity and efficiency, but it's danger in the widely misunderstanding and unintended usage. >> nowadays there are too many Unix novices, who misunderstand or >> misuse this, punching big holes in every security concern. > > Unfortunately even seasoned gurus easily create / fail to notice > holes! :( We are all humans and make mistakes, but a lot of those gurus forget about this ... ok, they are gurus and no more humans ;) See above: suid to *not root* is ok, suid *root* is flaw by design :( Harald