From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759526AbbA3CF5 (ORCPT ); Thu, 29 Jan 2015 21:05:57 -0500 Received: from smtp104.biz.mail.bf1.yahoo.com ([98.139.221.63]:34511 "EHLO smtp104.biz.mail.bf1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756383AbbA3CFz (ORCPT ); Thu, 29 Jan 2015 21:05:55 -0500 X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ROM0OuQVM1m_18b.2AZqHP7FAhx0DbUXwOv67WT.seAUYlm C9ItN7stipD8IvT9y6ZIUoXbrKrd8sQvaXsggvLsGQRZYVYtauZKtJYsacs4 WrHbiTmiUJHZjwvOVBi5HJHVeM5gksghAjA_wtSZg5yZTLld37ZnC1liRxbu qc3PPIZ2i6.gx5q1664.emyle2bJd5H8h4SL_berSAbZEAzcWkApPIfROq98 iE7Xdi7jjftR8WIPDkqcmYNAgdvy0J0Fi3bZ96sVwDWGsPoa4CdaDq_f0GiG tbbe_cly6uNsQV2NSfvBSaDf5z0HZN4zFRaGg3L4Yze2Ukb.cKupb8ddkOHj BDGwOKW_XS8u8Satw.UUjX8tlTdPOIjYKnr2v_Sdq6Qx_HOJMltxg9yGw19M YoxMFwUSKhhvBARQh.wUlyoFMxNSEkMCxXo7z4CFdHksv8C84EPik_XcxPk_ e3N8jO2VXGUdnZghM4fzh1ZUdE0JYX5NHsq6SGcDSVcTk8Gl5fEOlf1G9Q5k YK38qkIFzx2rh0P0Mobi2osxOwjQtBlqi X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Message-ID: <54CAE701.4060508@schaufler-ca.com> Date: Thu, 29 Jan 2015 18:05:53 -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: josh@joshtriplett.org CC: Iulia Manda , gnomes@lxorguk.ukuu.org.uk, serge.hallyn@canonical.com, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, paulmck@linux.vnet.ibm.com, 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> <20150130004325.GA14757@cloud> In-Reply-To: <20150130004325.GA14757@cloud> 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 4:43 PM, josh@joshtriplett.org 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. > So far that "longstanding position" consists of you griping that we're > not implementing authoritative LSM hooks for you and re-fighting that > battle for you. Patches for authoritative LSM hooks did indeed get > refused long ago, which is an excellent reason for us to not recast this > patch to reimplement them that way. The reason for bringing up authoritative hooks is that they allowed for a configuration like the one you have implemented. That fact was presented as an important reason why authoritative hooks could not be allowed. The point is not that I wanted authoritative hooks. The point is that the community opposed the very configuration you have implemented. I mention the authoritative hooks argument because that's where the issue was discussed. And if I felt sufficient strongly about bringing back authoritative hooks I wouldn't whinge to you about it. I'd go do it, and make a proper job of it. There are bigger and more important fish frying in the LSM community just now. > If it does turn out that the security maintainers in the kernel are open > to the idea of authoritative LSM hooks, by all means I would encourage > you to revisit such hooks. But there's a significant difference between > "add the ability to disable access controls" and "add a framework that > allows replacing the user/group security model with arbitrary access > controls", and it's not at all obvious that the "right" solution for the > former is an implementation of the latter; it also seems entirely > plausible that the kernel community remains opposed to the latter, which > does not necessarily rule out the former. My concern is that you've got a very specific configuration that is going to have all sort of application compatibility problems. I'm all for that as an experimental environment, but I don't think it's anywhere near ready or perhaps appropriate for upstream. > Given that, it would be helpful to hear feedback from more of the > community. Oh, I agree. I would also be curious about the user-space environment you hope to support with this kernel. >> 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 would expect that any security module would need to depend on NON_ROOT > (or MULTIUSER as v3 may end up calling it, per Geert Uytterhoeven's > suggestion). A kernel configuration with this option turned off > intentionally does not *have* user/group access controls. The intent of > this option isn't "turn standard access controls off so they get out of > the way of non-standard access controls"; the intent is "turn all access > controls off because there will never be unprivileged processes on this > system". Pretty limiting, and completely inappropriate for any system that gets connected as a part of the Internet of Things. So I'm back to thinking that while this may be a fun experiment, it doesn't belong as a supported upstream configuration. I hate thinking of Ubuntu running on top of this kernel, but someone will want to try it, you can bet. > So, on that basis, it sounds like v3 should add a dependency from > SECURITY to MULTIUSER. Your goals, your call, of course. If it's not generally useful though ... > - Josh Triplett