| View previous topic :: View next topic |
| Author |
Message |
Punchcutter
Guru
Joined: 11 Feb 2007
Posts: 354
|
 Posted: Mon Dec 06, 2021 4:29 am Post subject: Do I really need CONFIG_USER_NS? |
 |
|
I am just upgrading my kernel from 4.19.175 to 4.19.214 using gentoo-sources. In diffing the kernel configs that I got after running make oldconfig, I noticed that it seems that "upstream" (Gentoo?) had (quietly) turned on CONFIG_USER_NS (user namespaces). Make oldconfig did not present this to me for a choice.
I have kept that deliberately turned off because I have read it is a potential security hole, allowing root privilege escalation. Whenever I try to google and read more about these issues, my eyes glaze over... I am really not capable of digging deeply enough into this topic to be able to make my own decisions about security.
I recall that Chromium's build has "nagged" me in the past that I should have this turned on, but nothing seems to be broken without it. To this day, I am running Chromium (and Vivaldi, fwiw) without user namespaces, and also without SUID, and everything seems fine.
Is there some good reason that "upstream" is trying to force this on me? Is it safe? Does not having it prevent me from running Docker some day? Thx. |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Mon Dec 06, 2021 6:19 pm Post subject: |
|
|
User namespaces allow unprivileged user code access to call kernel code that was historically restricted to root, and to access only resources that either (a) could have been accessed without the user namespace or (b) are logically associated with the user namespace. In theory, all such code was reviewed and appropriately hardened before this access was granted. In practice, there have been bugs, particularly around input validation, where a previously root-only component could be exploited in a user namespace. For example, normally users cannot create new mount namespaces, but a user namespace allows that. If there is an ioctl that required privilege over a mount namespace, then before user namespaces, only root could use that ioctl. With user namespaces, an unprivileged user could create a new user namespace+mount namespace, and then use that root-only ioctl in the mount namespace. If that ioctl has an input handling bug, then the user namespace allows unprivileged users to trigger that bug. This is not a fault of the user namespace. It is the fault of the buggy ioctl.
The upside of user namespaces is that they allow user processes to build for themselves limited environments that previously required root. For example, historically only root could use chroot to isolate its view of the filesystem. With user namespaces, ordinary users can lock themselves into a chroot jail, which is desirable for web browsers because of their terrible security record (which is a direct consequence of the fascination with running everything in the browser, meaning the browser must be horribly complex, which leaves plenty of places for security bugs to creep in).
By running without user namespaces, you are likely hindering the browser's ability to confine the subprocesses that handle the most untrusted content. As long as you run only secure web browsers, this should be fine. (Note: a quick review of how often browser releases fix something nasty suggests there is no such thing as a secure web browser, if you want it to work with the modern Javascript infested web.) |
|
| Back to top |
|
|
Punchcutter
Guru
Joined: 11 Feb 2007
Posts: 354
|
| Posted: Tue Dec 07, 2021 9:06 am Post subject: |
|
|
Hu... thanks for taking the time to give a detailed explanation. Very helpful, and no eye glazing 
I hear you saying that setting CONFIG_USER_NS is advisable, in your opinion. I have taken that under consideration and perhaps not on this kernel upgrade, but maybe the next, relatively soon, I expect I'll decide to go for it. |
|
| Back to top |
|
|
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3623
|
| Posted: Tue Dec 07, 2021 11:50 am Post subject: |
|
|
Interesting...
Kernel unconfigured for now...
Hu's explanation is convincingly clear.
Currently reconsidering... 
Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here.
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. " |
|
| Back to top |
|
|
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3623
|
| Posted: Tue Dec 07, 2021 1:56 pm Post subject: |
|
|
Bit of context from kernel-5.15.6 | Code: | CONFIG_USER_NS:
│
│ This allows containers, i.e. vservers, to use user namespaces
│ to provide different user info for different servers.
│
│ When user namespaces are enabled in the kernel it is
│ recommended that the MEMCG option also be enabled and that
│ user-space use the memory control groups to limit the amount
│ of memory a memory unprivileged users can use.
│
│ If unsure, say N.
│
│ Symbol: USER_NS [=n]
│ Type : bool
│ Defined at init/Kconfig:1249
│ Prompt: User namespace
│ Depends on: NAMESPACES [=y]
│ Location:
│ -> General setup
│ -> Namespaces support (NAMESPACES [=y])
│ Selected by [n]:
│ - GENTOO_LINUX_PORTAGE [=n] && GENTOO_LINUX [=n] |
| Code: | │ Symbol: MEMCG [=n]
│ Type : bool
│ Defined at init/Kconfig:971
│ Prompt: Memory controller
│ Depends on: CGROUPS [=y]
│ Location:
│ -> General setup
│ (1) -> Control Group support (CGROUPS [=y])
│ Selects: PAGE_COUNTER [=n] && EVENTFD [=y] |
Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here.
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. " |
|
| Back to top |
|
|
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3623
|
| Posted: Tue Dec 07, 2021 3:12 pm Post subject: |
|
|
Afa kconfig-hardened-check app is concerned, CONFIG_USER_NS is indeed discouraged: | Code: | | CONFIG_USER_NS | is not set | clipos | cut_attack_surface | |
to be taken with a grain of salt, though.
Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here.
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. " |
|
| Back to top |
|
|
Punchcutter
Guru
Joined: 11 Feb 2007
Posts: 354
|
| Posted: Wed Dec 08, 2021 10:50 pm Post subject: |
|
|
So, this happened:
| Code: | 11:07 root@linux # grep USER_NS .config
# CONFIG_USER_NS is not set
11:07 root@linux # make
scripts/kconfig/conf --syncconfig Kconfig
CALL scripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
GZIP kernel/config_data.gz
Kernel: arch/x86/boot/bzImage is ready (#1)
Building modules, stage 2.
MODPOST 778 modules
11:07 root@linux #
00:25 root@linux # grep USER_NS .config
CONFIG_USER_NS=y
00:25 root@linux #
|
Giving this some thought, I realized that this must be being activated by some other kernel setting that has it as a "dependency"? Digging in to make menuconfig a bit, I find that it seems to be CONFIG_GENTOO_LINUX_PORTAGE. I suppose I don't want to turn that off. The help explains that all this stuff will be default pretty soon, so get used to it (in so many words).
Doesn't seem very "Gentoo" to force this kind of thing on people in order to be able to use the default package manager, but... as I noted earlier, I probably would have given in pretty soon anyway, so I guess soon is now
Last edited by Punchcutter on Wed Dec 08, 2021 11:04 pm; edited 1 time in total |
|
| Back to top |
|
|
halcon
l33t
Joined: 15 Dec 2019
Posts: 629
|
| Posted: Wed Dec 08, 2021 10:54 pm Post subject: |
|
|
| Punchcutter wrote: | | it's just a text file that doesn't know who or how it was changed, right? |
No! There are dependencies between options. Editing .config manually is strongly discouraged.
_________________
A wife asks her husband, a programmer:
- Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6?
He comes back with 6 cartons of milk.
- Why did you buy 6 cartons of milk?
- They had eggs. |
|
| Back to top |
|
|
Punchcutter
Guru
Joined: 11 Feb 2007
Posts: 354
|
| Posted: Wed Dec 08, 2021 11:05 pm Post subject: |
|
|
| halcon wrote: | | No! There are dependencies between options. Editing .config manually is strongly discouraged. |
Point taken. But I've already edited that bit out of my previous message  |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 4149
Location: Bavaria
|
| Posted: Wed Dec 08, 2021 11:20 pm Post subject: |
|
|
| Punchcutter wrote: | | Doesn't seem very "Gentoo" to force this kind of thing on people in order to be able to use the default package manager, but... as I noted earlier, I probably would have given in pretty soon anyway, so I guess soon is now |
Take a look into /usr/src/linux/distro/Kconfig and you will see which option enables more options. For example if you activate Gentoo-SYSTEMD you will have all what systemd recommends, even it is not neccessary, e.g. IPv6 is now hard enabled ... bad, if you dont want IPv6 and you want to disable it. The only chance you have is:
1. Edit the Kconfig file -or-
2. Dont enable Gentoo-systemd and enable all other needed for systemd by yourself |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1678
|
| Posted: Thu Dec 09, 2021 1:20 am Post subject: |
|
|
| Punchcutter wrote: | So, this happened:
| Code: | 11:07 root@linux # grep USER_NS .config
# CONFIG_USER_NS is not set
11:07 root@linux # make
scripts/kconfig/conf --syncconfig Kconfig
CALL scripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
GZIP kernel/config_data.gz
Kernel: arch/x86/boot/bzImage is ready (#1)
Building modules, stage 2.
MODPOST 778 modules
11:07 root@linux #
00:25 root@linux # grep USER_NS .config
CONFIG_USER_NS=y
00:25 root@linux #
|
Giving this some thought, I realized that this must be being activated by some other kernel setting that has it as a "dependency"? Digging in to make menuconfig a bit, I find that it seems to be CONFIG_GENTOO_LINUX_PORTAGE. I suppose I don't want to turn that off. The help explains that all this stuff will be default pretty soon, so get used to it (in so many words).
Doesn't seem very "Gentoo" to force this kind of thing on people in order to be able to use the default package manager, but... as I noted earlier, I probably would have given in pretty soon anyway, so I guess soon is now |
You're not being forced to (you don't even have to use that option) -- it's just recommended because it's a common set of things needed to make things work correctly, in particular, for Portage's sandboxing. Feel free to turn off the CONFIG_GENTOO_LINUX_* options and manually enable the ones you need (with the tradeoffs from disabling some of them) if you want more control?
As Hu has explained well, most people should really enable this anyway. Not doing so is like disabling seccomp -- your system is likely to be less secure as a result. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
