On 18.10.2015 22:48, Richard Weinberger wrote: > Am 18.10.2015 um 22:41 schrieb Tobias Markus: >> On 18.10.2015 22:21, Richard Weinberger wrote: >>> Am 18.10.2015 um 22:13 schrieb Tobias Markus: >>>> On 17.10.2015 22:17, Richard Weinberger wrote: >>>>> On Sat, Oct 17, 2015 at 5:58 PM, Tobias Markus <tobias@xxxxxxxxx> wrote: >>>>>> One question remains though: Does this break userspace executables that >>>>>> expect being able to create user namespaces without priviledge? Since >>>>>> creating user namespaces without CAP_SYS_ADMIN was not possible before >>>>>> Linux 3.8, programs should already expect a potential EPERM upon calling >>>>>> clone. Since creating a user namespace without CAP_SYS_USER_NS would >>>>>> also cause EPERM, we should be on the safe side. >>>>> >>>>> In case of doubt, yes it will break existing software. >>>>> Hiding user namespaces behind CAP_SYS_USER_NS will not magically >>>>> make them secure. >>>>> >>>> The goal is not to make user namespaces secure, but to limit access to >>>> them somewhat in order to reduce the potential attack surface. >>> >>> We have already a framework to reduce the attack surface, seccomp. >>> There is no need to invent new capabilities for every non-trivial >>> kernel feature. >>> >>> I can understand the user namespaces seems scary and had bugs. >>> But which software didn't? >>> >>> Are there any unfixed exploitable bugs in user namespaces in recent kerenls? >>> >>> Thanks, >>> //richard >> >> Isn't seccomp about setting a per-thread syscall filter? Correct me if >> I'm wrong, but I don't know of any way of using seccomp to globally ban >> the use of clone or unshare with CLONE_NEWUSER except for a few >> whiteliste executables, and that's the idea of this hypothetical capability. > > This is correct. > If you want it globally you can still use LSM. The LSM isn't really the one-size-fits-all solution that distributions like to ship in their standard kernels... > >> Sure, there are no known exploitable bugs in recent kernels, but would >> you guarantee that for the next 10 years? Every software has bugs, some >> of them exploitable, no amount of testing can prevent that. I'm not >> paranoid, but on the other hand, why should every Linux user having >> CONFIG_USER_NS enabled have to expose more attack surface than he >> absolutely has to? > > And what about all the other kernel features? > I really don't get why you choose user namespaces as your enemy. I didn't choose user namespaces as my enemy, I chose user namespaces as the feature that I would really like to have shipped by default by my and by other distributions, but that's sadly often disabled for security concerns. Is there any solution that can be safely used by distributions to have user namespaces enabled by default without worrying about security? > >> Richard, would you run an Apache HTTP server exposed to the internet on >> your own laptop, without any security precautions? According to your >> reasoning, Apache is surely scary and has many bugs, but every software >> has bugs, right? > > This argument is bogus and you know that too. Sure, it's exaggregated, but still, if it's possible to reduce the attack surface for every user without great effort, why shouldn't that be done? To give an example more closely resembling the matter in hand: CAP_SYSLOG allows viewing kernel addresses when kptr_restrict is enabled. But why limit access to the kernel symbols? There is nothing an attacker can do with them, except there is a kernel bug. But before we continue arguing endlessly, I just got an idea: What about adding a sysctl to enable/disable enforcement of the hypothetical CAP_SYS_USER_NS, just like with /proc/sys/kernel/kptr_restrict and CAP_SYSLOG? Would also prevent any potential userspace breakage. > >> I really don't want to introduce a user-facing API change just for the >> fun of it - so if there's any better way to do this, please tell me. > > As I said, it really don't see why we should treat user namespaces in a special > way. It is a kernel feature like many others are. If you don't trust it, disable it. And there's the problem: It's either 100% (unpriviledged user namespaces without limit) or 0% (disable user namespaces entirely). > > Thanks, > //richard -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
