Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #72196 > unrolled thread
| Started by | HolyTaint <holytaint@disroot.org> |
|---|---|
| First post | 2021-06-15 13:10 +0200 |
| Last post | 2021-06-20 23:10 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.debian.kernel
User NS usage and attack surface mitigation on debian HolyTaint <holytaint@disroot.org> - 2021-06-15 13:10 +0200
Re: User NS usage and attack surface mitigation on debian HolyTaint <holytaint@disroot.org> - 2021-06-17 05:30 +0200
Re: User NS usage and attack surface mitigation on debian Ben Hutchings <ben@decadent.org.uk> - 2021-06-20 23:10 +0200
| From | HolyTaint <holytaint@disroot.org> |
|---|---|
| Date | 2021-06-15 13:10 +0200 |
| Subject | User NS usage and attack surface mitigation on debian |
| Message-ID | <Cqf7b-5i9-9@gated-at.bofh.it> |
I stumbled upon this answer from three years ago (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446) "User namespaces *are* enabled - but by default, they can only be created by root". I need clarifications on that, cause I didn't quite know how namespace management works. I experimented a bit, from what I got it creates a namespace originating from the user asking it, and using it as normal user was disabled by default because it clearly adds lots of attack surface by exposing code that would normally be used by just root. Also in this little space there is a mapping between namespace users and originating user What I didn't quite got is, does this patch allow creating namespaces belonging to an user from root, thus avoiding the possibility of privilege escalation, or having user namespaces running from unprivileged users is a threat by itself? I ask this because I'm particularly concerned about unprivileged containers support. While it is certainly good not having access to critical pieces of the linux kernel to regular UIDs it may be counterproductive in cases of a single user deputated just for running unprivileged containers, if there is no other way of creating such unprivileged namespaces If there are some infos I'm missing please explain them or link resources, I searched what I could but apparently it wasn't enough
[toc] | [next] | [standalone]
| From | HolyTaint <holytaint@disroot.org> |
|---|---|
| Date | 2021-06-17 05:30 +0200 |
| Message-ID | <CqQT7-2Nv-1@gated-at.bofh.it> |
| In reply to | #72196 |
Tue, 15 Jun 2021 13:04:54 +0200 HolyTaint <holytaint@disroot.org>: > I stumbled upon this answer from three years ago (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446) > "User namespaces *are* enabled - but by default, they can only be created by root". > I need clarifications on that, cause I didn't quite know how namespace management works. > I experimented a bit, from what I got it creates a namespace originating from the user asking it, and using it as normal user was disabled by default because it clearly adds lots of attack surface by exposing code that would normally be used by just root. Also in this little space there is a mapping between namespace users and originating user > > What I didn't quite got is, does this patch allow creating namespaces belonging to an user from root, thus avoiding the possibility of privilege escalation, or having user namespaces running from unprivileged users is a threat by itself? > > I ask this because I'm particularly concerned about unprivileged containers support. While it is certainly good not having access to critical pieces of the linux kernel to regular UIDs it may be counterproductive in cases of a single user deputated just for running unprivileged containers, if there is no other way of creating such unprivileged namespaces > > If there are some infos I'm missing please explain them or link resources, I searched what I could but apparently it wasn't enough > Please give me infos on this issue. I believe it is really important for developing solutions which make full use of the linux kernel namespace capabilities while avoiding potential pitfalls
[toc] | [prev] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2021-06-20 23:10 +0200 |
| Message-ID | <CscRz-4v7-5@gated-at.bofh.it> |
| In reply to | #72196 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, 2021-06-15 at 13:04 +0200, HolyTaint wrote: > I stumbled upon this answer from three years ago ( > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446) > "User namespaces *are* enabled - but by default, they can only be > created by root". Note that this default has been changed in the kernel version available in testing/unstable. > I need clarifications on that, cause I didn't quite know how > namespace management works. > I experimented a bit, from what I got it creates a namespace > originating from the user asking it, and using it as normal user was > disabled by default because it clearly adds lots of attack surface by > exposing code that would normally be used by just root. Also in this > little space there is a mapping between namespace users and > originating user > > What I didn't quite got is, does this patch allow creating namespaces > belonging to an user from root, thus avoiding the possibility of > privilege escalation, or having user namespaces running from > unprivileged users is a threat by itself? [...] If by "belonging to a user" you mean "user appears as uid 0 inside the user namespace, and may have some capabilities there" - then yes, it is possible for root to create a user namespace belonging to another user. (I don't know exactly how to do that, though.) Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web