mailing list of musl libc
 help / color / mirror / Atom feed
From: Rich Felker <>
To: Felix Kyros Ang <>
Subject: Re: [musl] Consider making issetugid compatible with Linux capabilities
Date: Sun, 2 May 2021 15:53:57 -0400
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, May 02, 2021 at 11:40:19AM -0400, Felix Kyros Ang wrote:
> Hello,
> Musl implements the BSDs' issetugid syscall as a libc function (which
> is awesome). Currently, musl's issetugid indicates that the
> environment is tainted when it detects additional Linux capabilities
> on the executable (set through setcap for example). This causes the
> environment to be cleared when the executable is run, leading to some
> program breakages. For instance, some libdbus functions use the
> environment to identify the dbus session bus ID, and those programs
> (linked to libdbus) will fail if Linux capabilities are added to it.

What program is clearing the environment as a result of this? That's
probably where the problem lies.

> I wonder if it would be possible to tweak musl such that it does not
> consider Linux capabilities a tainted privilege. Alternatively, it
> could consider only the "highly overloaded" capabilities (such as
> CAP_SYS_ADMIN) as tainted privileges. Here are my thoughts on why this
> could be a good idea:

No, considering capabilities as "tainted" is an essential security
property of the interface. Without that, you might as well have just
given the invoking user full unconstrained access to the capability.
At least internally (, it's trivial to gain full control
over a process if you can bypass this, e.g. with LD_PRELOAD, malicious
message catalogs that enable format vulnerabilities, etc. When the
application is using issetuid() itself, whether it's possible to gain
full control over execution depends on the application. However, if
it's doing what you describe -- execing children while passing through
the environment that it inherited -- then it's trivial to gain control
by passing LD_PRELOAD libs to those children.

> Looking at the code, it looks like musl's issetugid function returns
> the value when called, and I couldn't find where
>'s value is initialised. If someone could point me in the
> right direction, I'll see if I can maybe send in a patch that proposes
> a possible solution.

It comes from AT_SECURE in the aux vector. See ldso/dynlink.c (dynamic
linked case) and sec/env/__libc_start_main.c


      reply	other threads:[~2021-05-02 19:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-02 15:40 Felix Kyros Ang
2021-05-02 19:53 ` Rich Felker [this message]

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:

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

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ \
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:

code repositories for the project(s) associated with this inbox:

AGPL code for this site: git clone