Re: [PATCH] userns/capability: Add user namespace capability
On Sat, Oct 17, 2015 at 5:58 PM, Tobias Markus 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. -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] userns/capability: Add user namespace capability
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] userns/capability: Add user namespace capability
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 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. > 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. > 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. > 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. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] userns/capability: Add user namespace capability
Am 18.10.2015 um 23:49 schrieb Tobias Markus: > 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. My argument stands, hiding user namespaces behind whatever switch and rendering it into a second class citizen does not improve its security. Especially ad-hoc solutions are not expedient. Reducing the attack surface must not lead to gazillions of new capabilities, sysctl switches, etc... user namespaces are neither the first nor the last "critical" kernel feature. I'm sure RHEL will ship a SELinux boolean to disable user namespaces as they do for many other OS features. This is fine and exactly why we have LSM. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] userns/capability: Add user namespace capability
Am 19.10.2015 um 14:36 schrieb Yves-Alexis Perez: > On dim., 2015-10-18 at 20:41 -0500, Serge E. Hallyn wrote: >> We shouldn't need a long-term solution. Your concern is bugs. After >> some time surely we'll feel that we have achieved a stable solution? > > But this is actually the whole point: we need a long term solution, because > they will always be bug, whether in user namespaces or in others parts exposed > by user namespaces. It's fine to fix them when we find them, but that still > means they're exploitable even before we know about them. We still find bugs > in code written years ago, it's quite certain there are bugs in current code. You can replace the term "user namespace" with any other non-trivial kernel subsystem. There will always be bugs. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] User namespace mount updates
On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee wrote: > On Tue, Nov 17, 2015 at 05:55:06PM +, Al Viro wrote: >> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote: >> >> > Shortly after that I plan to follow with support for ext4. I've been >> > fuzzing ext4 for a while now and it has held up well, and I'm currently >> > working on hand-crafted attacks. Ted has commented privately (to others, >> > not to me personally) that he will fix bugs for such attacks, though I >> > haven't seen any public comments to that effect. >> >> _Static_ attacks, or change-image-under-mounted-fs attacks? > > Right now only static attacks, change-image-under-mounted-fs attacks > will be next. Do we *really* need to enable unprivileged mounting of kernel filesystems? What about just enabling fuse and implement ext4 and friends as fuse filesystems? Using the approaching Linux Kernel Libary[1] this is easy. [1] https://lkml.org/lkml/2015/11/3/706 -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] User namespace mount updates
Am 17.11.2015 um 20:21 schrieb Seth Forshee: > On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote: >> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee >> wrote: >>> On Tue, Nov 17, 2015 at 05:55:06PM +, Al Viro wrote: >>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote: >>>> >>>>> Shortly after that I plan to follow with support for ext4. I've been >>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently >>>>> working on hand-crafted attacks. Ted has commented privately (to others, >>>>> not to me personally) that he will fix bugs for such attacks, though I >>>>> haven't seen any public comments to that effect. >>>> >>>> _Static_ attacks, or change-image-under-mounted-fs attacks? >>> >>> Right now only static attacks, change-image-under-mounted-fs attacks >>> will be next. >> >> Do we *really* need to enable unprivileged mounting of kernel filesystems? >> What about just enabling fuse and implement ext4 and friends as fuse >> filesystems? >> Using the approaching Linux Kernel Libary[1] this is easy. > > I haven't looked at this project, but I'm guessing that programs must be > written specifically to make use of it? I.e. you can't just use the > mount syscall, and thus all existing software still doesn't work? You can easy bridge fuse and the LKL, I did already a hacky PoC. Worked nicely. Octavian's tree has some nice examples, and AFAIK he is currently working on a "mount any kernel fs via fuse" tool. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] User namespace mount updates
Am 17.11.2015 um 20:25 schrieb Octavian Purdila: > On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee > wrote: >> >> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote: >>> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee >>> wrote: >>>> On Tue, Nov 17, 2015 at 05:55:06PM +, Al Viro wrote: >>>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote: >>>>> >>>>>> Shortly after that I plan to follow with support for ext4. I've been >>>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently >>>>>> working on hand-crafted attacks. Ted has commented privately (to others, >>>>>> not to me personally) that he will fix bugs for such attacks, though I >>>>>> haven't seen any public comments to that effect. >>>>> >>>>> _Static_ attacks, or change-image-under-mounted-fs attacks? >>>> >>>> Right now only static attacks, change-image-under-mounted-fs attacks >>>> will be next. >>> >>> Do we *really* need to enable unprivileged mounting of kernel filesystems? >>> What about just enabling fuse and implement ext4 and friends as fuse >>> filesystems? >>> Using the approaching Linux Kernel Libary[1] this is easy. >> >> I haven't looked at this project, but I'm guessing that programs must be >> written specifically to make use of it? I.e. you can't just use the >> mount syscall, and thus all existing software still doesn't work? >> > > The projects includes a lklfuse program that uses fuse to mount a > fileystem image. Cool. I gave it a try. It seems to work fine, but only if I run it in foreground (using -d) otherwise fuse blocks every filesystem request. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] User namespace mount updates
On Wed, Nov 18, 2015 at 4:13 PM, Al Viro wrote: > On Wed, Nov 18, 2015 at 09:05:12AM -0600, Seth Forshee wrote: > >> Yes, the host admin. I'm not talking about trusting the admin inside the >> container at all. > > Then why not have the same host admin just plain mount it when setting the > container up and be done with that? From the host namespace, before spawning > the docker instance or whatever framework you are using. IDGI... Because hosting companies sell containers as "full virtual machines" and customers expect to be able mount stuff like disk images they upload. -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] User namespace mount updates
Am 19.11.2015 um 08:47 schrieb James Morris: > On Wed, 18 Nov 2015, Richard Weinberger wrote: > >> On Wed, Nov 18, 2015 at 4:13 PM, Al Viro wrote: >>> On Wed, Nov 18, 2015 at 09:05:12AM -0600, Seth Forshee wrote: >>> >>>> Yes, the host admin. I'm not talking about trusting the admin inside the >>>> container at all. >>> >>> Then why not have the same host admin just plain mount it when setting the >>> container up and be done with that? From the host namespace, before >>> spawning >>> the docker instance or whatever framework you are using. IDGI... >> >> Because hosting companies sell containers as "full virtual machines" >> and customers expect to be able mount stuff like disk images they upload. > > I don't think this is a valid reason for merging functionality into the > kernel. Erm, I don't want this in the kernel. That's why I've proposed the lklfuse approach. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] User namespace mount updates
Am 19.11.2015 um 15:37 schrieb Colin Walters: > On Thu, Nov 19, 2015, at 02:53 AM, Richard Weinberger wrote: > >> Erm, I don't want this in the kernel. That's why I've proposed the lklfuse >> approach. > > I already said this before but just to repeat, since I'm confused: > > How would "lklfuse" be different from http://libguestfs.org/ > which we at Red Hat (and a number of other organizations) > use quite widely now for build systems, debugging etc. Currently libguestfs has a rather huge overhead because it boots a full virtual machine and hence a lot of communication is needed. With LKL you can use Linux as Library and link it to fuse. AFAIK Richard added already a LKL backend to libguestfs. :-) > In the end it's just running the kernel in KVM with a custom protocol, > with support for non-filesystem things like "install a bootloader", > and it already supports FUSE. > > I'm pretty firmly with Al here - the attack surface increase here > is too great, and we'd likely turn this off if it even did make it > into the kernel. Agreed. This is why I'm promoting the fuse solution. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] User namespace mount updates
Am 19.11.2015 um 15:21 schrieb Serge E. Hallyn: > On Thu, Nov 19, 2015 at 08:53:26AM +0100, Richard Weinberger wrote: >> Am 19.11.2015 um 08:47 schrieb James Morris: >>> On Wed, 18 Nov 2015, Richard Weinberger wrote: >>> >>>> On Wed, Nov 18, 2015 at 4:13 PM, Al Viro wrote: >>>>> On Wed, Nov 18, 2015 at 09:05:12AM -0600, Seth Forshee wrote: >>>>> >>>>>> Yes, the host admin. I'm not talking about trusting the admin inside the >>>>>> container at all. >>>>> >>>>> Then why not have the same host admin just plain mount it when setting the >>>>> container up and be done with that? From the host namespace, before >>>>> spawning >>>>> the docker instance or whatever framework you are using. IDGI... >>>> >>>> Because hosting companies sell containers as "full virtual machines" >>>> and customers expect to be able mount stuff like disk images they upload. >>> >>> I don't think this is a valid reason for merging functionality into the >>> kernel. >> >> Erm, I don't want this in the kernel. That's why I've proposed the lklfuse >> approach. > > That would require the fuse-in-containers functionality, right? Correct. Still a less large attack surface. :-) Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
