From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759443AbbA3CZa (ORCPT ); Thu, 29 Jan 2015 21:25:30 -0500 Received: from smtp104.biz.mail.bf1.yahoo.com ([98.139.221.63]:37961 "EHLO smtp104.biz.mail.bf1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752517AbbA3CZ0 (ORCPT ); Thu, 29 Jan 2015 21:25:26 -0500 X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cWujG_QVM1mRKhCLiQZipQiWia3f2SSVQCt1Te.N_9aUhSQ j9s10WdB9YUgwGWf.piFyK9ObvzFDwma8IBCIcrUdh1zYyGLQxU9WzqATs_1 y9Fn2.VnbJej565i2PaaJ3asn.af4yWDG.NG9Y33rP03.R8_gBqimpMN_A0h yY7WyHSJwzNerK6plZwnr5OgIha4_wB.XQjhQgm718oNspTCapUDX8Sz9LWx 2.8pNvfJl5BASzc3c6e4_nz8v3RqqcbbTGfb7Mm2dKZCUMJ444mXADBY9TEb ju9IwfQYWNmT9Bs_n0rophyokbKH2mWy7LxbdMRZoyDi__UzlFT1V2ZwDTkd nwi0AegFVdqOiVlsAn8zax07Zx0W3zz5jHBCEcaJzQqxbFOeN6YLgyY.yrh4 2dqQ9ZIRL472oAUKDOjGpvwyzYPfKZ29pyv2CZ6ewngc19vKsxeay7XlonyS dnDSOgYr9Mxjm8bc8IgTxnvUh8CxvS5Isu7JSzY.pNec8VhAnredklxwq4y_ p4ETzZHyZ6xkrIj9L81GpzXHc X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Message-ID: <54CAEB93.5090508@schaufler-ca.com> Date: Thu, 29 Jan 2015 18:25:23 -0800 From: Casey Schaufler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: paulmck@linux.vnet.ibm.com CC: Iulia Manda , gnomes@lxorguk.ukuu.org.uk, serge.hallyn@canonical.com, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, josh@joshtriplett.org, peterz@infradead.org, mhocko@suse.cz, LSM , Casey Schaufler Subject: Re: [PATCH v2] kernel: Conditionally support non-root users, groups and capabilities References: <20150129184311.GA6404@winterfell> <54CAC5EE.8060107@schaufler-ca.com> <20150130003228.GJ19109@linux.vnet.ibm.com> <54CADDA4.4040602@schaufler-ca.com> <20150130013600.GM19109@linux.vnet.ibm.com> In-Reply-To: <20150130013600.GM19109@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/29/2015 5:36 PM, Paul E. McKenney wrote: > On Thu, Jan 29, 2015 at 05:25:56PM -0800, Casey Schaufler wrote: >> On 1/29/2015 4:32 PM, Paul E. McKenney wrote: >>> On Thu, Jan 29, 2015 at 03:44:46PM -0800, Casey Schaufler wrote: >>>> On 1/29/2015 10:43 AM, Iulia Manda wrote: >>>>> There are a lot of embedded systems that run most or all of their functionality >>>>> in init, running as root:root. For these systems, supporting multiple users is >>>>> not necessary. >>>>> >>>>> This patch adds a new symbol, CONFIG_NON_ROOT, that makes support for non-root >>>>> users, non-root groups, and capabilities optional. >>>>> >>>>> When this symbol is not defined, UID and GID are zero in any possible case >>>>> and processes always have all capabilities. >>>>> >>>>> The following syscalls are compiled out: setuid, setregid, setgid, >>>>> setreuid, setresuid, getresuid, setresgid, getresgid, setgroups, getgroups, >>>>> setfsuid, setfsgid, capget, capset. >>>>> >>>>> Also, groups.c is compiled out completely. >>>>> >>>>> This change saves about 25 KB on a defconfig build. >>>>> >>>>> The kernel was booted in Qemu. All the common functionalities work. Adding >>>>> users/groups is not possible, failing with -ENOSYS. >>>>> >>>>> Bloat-o-meter output: >>>>> add/remove: 7/87 grow/shrink: 19/397 up/down: 1675/-26325 (-24650) >>>>> >>>>> Signed-off-by: Iulia Manda >>>>> Reviewed-by: Josh Triplett >>>> v2 does nothing to address the longstanding position of >>>> the community that disabling the traditional user based >>>> access controls is unacceptable. >>>> >>>> If the community has abandoned that position, and I see no >>>> reason to believe that is true, the correct implementation >>>> is to rework the LSM from an additional controls model to >>>> an authoritative hook model. >>>> >>>> Speaking of the LSM, what is your expectation regarding the >>>> use of security modules in addition to "NON_ROOT"? Is it >>>> forbidden, allowed or encouraged? >>> I am guessing that people who remove uids and gids from their >>> kernels would tend not to add LSM. From what I understand, these >>> kernels are designed for special-purpose applications that have >>> very limited and stylized interactions with the outside world. >>> Applications that, back in the day, would have been written to >>> run on bare metal without any OS whatsoever. >> Linux is still going to be too big for those applications. Taking >> the UID, GID and capability processing out is, at 25k, hardly significant. >> Yes, you'll save some processing time, but the benchmarks I've run in the >> dim dark past indicated that the impact is actually trivial. I would of >> course invite the advocates of this patch to produce numbers. No, if you >> are looking to switch from a RTOS to a Linux kernel, UID processing isn't >> going to be your first (second, or third) concern. > A few K here, a few K there, and pretty soon you actually fit into the > small-memory 32-bit SoCs. I do not believe that the processing time > is the issue. And UNIX, with UID and GID processing, used to run in 64K of RAM, without swap or paging. Bluntly, there are many other places to look before you go here. >> As for LSMs, I can easily see putting in the security model from the old >> RTOS on top of a NON_ROOT configuration. Won't that be fun when the CVEs >> start to fly? >> >> Do you think you'll be running system services like systemd on top of this? >> Anyone *else* remember what happened when they put capability handling into >> sendmail? > Nope, I don't expect these systems to be using LSM, systemd, or sendmail. > I think that many of these will instead run the application directly > out of the init process. Where an "application" might be something like CrossWalk, which is going to pull in all sorts of fun services that no one will want to maintain or change for the environment. Resulting in all sorts of security issues. It would be inappropriate for me to sit aside and let you go in that direction unwarned. I'm not going to try to stop you, because I know that's futile. Let me know what I can do to help when the time comes. > > Thanx, Paul > >