linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: alx@kernel.org, serge@hallyn.com, christian@brauner.io,
	ipedrosa@redhat.com, gscrivan@redhat.com,
	andreas.gruenbacher@gmail.com
Cc: acl-devel@nongnu.org, linux-man@vger.kernel.org,
	linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	ebiederm@xmission.com, Richard Weinberger <richard@nod.at>
Subject: [PATCH 0/3] Document impact of user namespaces and negative permissions
Date: Tue, 29 Aug 2023 22:58:30 +0200	[thread overview]
Message-ID: <20230829205833.14873-1-richard@nod.at> (raw)

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

-- 
2.26.2


             reply	other threads:[~2023-08-29 20:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-29 20:58 Richard Weinberger [this message]
2023-08-29 20:58 ` [PATCH 1/3] man: Document pitfall with negative permissions and user namespaces Richard Weinberger
2023-08-30  8:19   ` Christian Brauner
2023-08-29 20:58 ` [PATCH 2/3] user_namespaces.7: " Richard Weinberger
2023-08-29 21:32   ` Alejandro Colomar
2023-08-29 21:38     ` Alejandro Colomar
2023-08-29 21:40       ` Richard Weinberger
2023-08-29 21:39     ` Richard Weinberger
2023-08-29 21:40       ` Alejandro Colomar
2023-08-30  9:26     ` Alejandro Colomar
2023-08-30  8:18   ` Christian Brauner
2023-08-29 20:58 ` [PATCH 3/3] man: " Richard Weinberger
2023-08-30  8:19   ` Christian Brauner
2023-08-29 21:26 ` [PATCH 0/3] Document impact of user namespaces and negative permissions Alejandro Colomar
2023-08-29 21:32   ` Richard Weinberger
2023-09-13 14:35     ` Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230829205833.14873-1-richard@nod.at \
    --to=richard@nod.at \
    --cc=acl-devel@nongnu.org \
    --cc=alx@kernel.org \
    --cc=andreas.gruenbacher@gmail.com \
    --cc=christian@brauner.io \
    --cc=ebiederm@xmission.com \
    --cc=gscrivan@redhat.com \
    --cc=ipedrosa@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).