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 <iulia.mand...@gmail.com> >>>>> Reviewed-by: Josh Triplett <j...@joshtriplett.org> >>>> 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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
