mbox series

[0/3] Document impact of user namespaces and negative permissions

Message ID 20230829205833.14873-1-richard@nod.at (mailing list archive)
Headers show
Series Document impact of user namespaces and negative permissions | expand

Message

Richard Weinberger Aug. 29, 2023, 8:58 p.m. UTC
I'm sending out this patch series to document the current situation regarding
negative permissions and user namespaces.

From what I understand, the general agreement is that negative permissions
are not recommended and should be avoided. This is why the ability to somewhat
bypass these permissions using user namespaces is tolerated, as it's deemed
not worth the complexity to address this without breaking exsting programs such
as podman.

To be clear, the current way of bypassing negative permissions, whether DAC or
ACL, isn't a result of a kernel flaw. The kernel issue related to this was
resolved with CVE-2014-8989. Currently, certain privileged helpers like
newuidmap allow regular users to create user namespaces with subordinate user
and group ID mappings.
This allows users to effectively drop their extra group memberships.

I recently stumbled upon this behavior while looking into how rootless containers
work. In conversations with the maintainers of the shadow package, I learned that
this behavior is both known and intended.
So, let's make sure to document it as well.

Thanks,
//richard

Comments

Alejandro Colomar Aug. 29, 2023, 9:26 p.m. UTC | #1
Hello Richard,

On 2023-08-29 22:58, Richard Weinberger wrote:
> I'm sending out this patch series to document the current situation regarding
> negative permissions and user namespaces.
> 
> From what I understand, the general agreement is that negative permissions
> are not recommended and should be avoided. This is why the ability to somewhat
> bypass these permissions using user namespaces is tolerated, as it's deemed
> not worth the complexity to address this without breaking exsting programs such
> as podman.
> 
> To be clear, the current way of bypassing negative permissions, whether DAC or
> ACL, isn't a result of a kernel flaw. The kernel issue related to this was
> resolved with CVE-2014-8989. Currently, certain privileged helpers like
> newuidmap allow regular users to create user namespaces with subordinate user
> and group ID mappings.
> This allows users to effectively drop their extra group memberships.
> 
> I recently stumbled upon this behavior while looking into how rootless containers
> work. In conversations with the maintainers of the shadow package, I learned that
> this behavior is both known and intended.
> So, let's make sure to document it as well.

Can you please provide a small shell session where this is exemplified?
I.e., please show how a user (or group member) can read a file with
u= (or g= ) permissions on the file.

I.e., what can you do from here?:

$ echo bar > foo
$ ls -l foo
-rw-r--r-- 1 alx alx 4 Aug 29 23:24 foo
$ chmod u= foo
$ sudo chmod g= foo
$ ls -l foo
-------r-- 1 alx alx 4 Aug 29 23:24 foo
$ cat foo
cat: foo: Permission denied


Cheers,
Alex
Richard Weinberger Aug. 29, 2023, 9:32 p.m. UTC | #2
----- Ursprüngliche Mail -----
> Von: "Alejandro Colomar" <alx@kernel.org>
> Can you please provide a small shell session where this is exemplified?

Sure. I sent the following to the shadow maintainers privately on Friday,
but since the issue is already known for years I don't hesitate to share.

# On a Debian Bookworm
# So far no entries are installed.
$ cat /etc/subuid

# useradd automatically does so.
$ useradd -m rw
$ cat /etc/subuid
rw:100000:65536

# Let's create a folder where the group "nogames" has no permissions.
$ mkdir /games
$ echo win > /games/game.txt
$ groupadd nogames
$ chown -R root:nogames /games
$ chmod 705 /games

# User "rw" must not play games
$ usermod -G nogames rw

# Works as expected
rw@localhost:~$ id
uid=1000(rw) gid=1000(rw) groups=1000(rw),1001(nogames)
rw@localhost:~$ cat /games/game.txt
cat: /games/game.txt: Permission denied

# By using unshare (which utilizes the newuidmap helper) we can get rid of the "nogames" group.
rw@localhost:~$ unshare -S 0 -G 0 --map-users=100000,0,65536 --map-groups=100000,0,65536 id
uid=0(root) gid=0(root) groups=0(root)

rw@localhost:~$ unshare -S 0 -G 0 --map-users=100000,0,65536 --map-groups=100000,0,65536 cat /games/game.txt
win

Thanks,
//richard
Alejandro Colomar Sept. 13, 2023, 2:35 p.m. UTC | #3
Hi Richard,

On 2023-08-29 23:32, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Alejandro Colomar" <alx@kernel.org>
>> Can you please provide a small shell session where this is exemplified?
> 
> Sure. I sent the following to the shadow maintainers privately on Friday,
> but since the issue is already known for years I don't hesitate to share.
> 
> # On a Debian Bookworm
> # So far no entries are installed.
> $ cat /etc/subuid
> 
> # useradd automatically does so.
> $ useradd -m rw
> $ cat /etc/subuid
> rw:100000:65536
> 
> # Let's create a folder where the group "nogames" has no permissions.
> $ mkdir /games
> $ echo win > /games/game.txt
> $ groupadd nogames
> $ chown -R root:nogames /games
> $ chmod 705 /games
> 
> # User "rw" must not play games
> $ usermod -G nogames rw
> 
> # Works as expected
> rw@localhost:~$ id
> uid=1000(rw) gid=1000(rw) groups=1000(rw),1001(nogames)
> rw@localhost:~$ cat /games/game.txt
> cat: /games/game.txt: Permission denied
> 
> # By using unshare (which utilizes the newuidmap helper) we can get rid of the "nogames" group.
> rw@localhost:~$ unshare -S 0 -G 0 --map-users=100000,0,65536 --map-groups=100000,0,65536 id
> uid=0(root) gid=0(root) groups=0(root)
> 
> rw@localhost:~$ unshare -S 0 -G 0 --map-users=100000,0,65536 --map-groups=100000,0,65536 cat /games/game.txt
> win
> 
> Thanks,
> //richard

Thanks!

Please include this in the commit message (at least for the Linux man-pages
one).

Cheers,
Alex