From nobody Thu Oct 31 05:18:11 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XfC1p4g5Fz5b6WS for ; Thu, 31 Oct 2024 05:18:06 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XfC1n4Z1Vz583N for ; Thu, 31 Oct 2024 05:18:05 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=TofRfaEb; spf=pass (mx1.freebsd.org: domain of vini.ipsmaker@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) smtp.mailfrom=vini.ipsmaker@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-539e59dadebso657937e87.0 for ; Wed, 30 Oct 2024 22:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730351883; x=1730956683; darn=freebsd.org; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JpTK4NuFsNXFPW+B9FlMPlBOSN4e2TMrKMOP/5Um9YE=; b=TofRfaEbG1RiJz1airpRcZ0Ln1m65L+kp/axdKpQqtZ+aIPcQLSPEBk44k3JuhAcu7 vfeedVAM3Ols6VuQiTtyO/+MAwxoNlRf1fSR0ilQXk1LBICaxmVmPnCA0XQdmR/l4XpZ eiUEbIM5y6yIQ9rAmoEoitinC7lUJ2kqOjW6dZBcy6C1BA4H9vfZ8VDvOqb6mugarajU oHEy3sGBbvWCIpYOxzZ5utx7dT0lc1JZplFDdyxgyqg20lazz1oV69l0ncUFqIKeghjQ RtQSNAR0jCgBhhkYwKYmrcczmqkaIdW3ZJAaRnktX4C/Jgy486lW74AjMqjjRZrVYgEt oHBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730351883; x=1730956683; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JpTK4NuFsNXFPW+B9FlMPlBOSN4e2TMrKMOP/5Um9YE=; b=hYpm1tarURtFjtLTgJkBHfgeeRKZAE1jwzsYPRhFatqrbXzSe9wweTR8zLo7SEXjzB RCBkSFG/xYHwqIa9AYdROH3XgnDO8Z8mkGYKtfzmLWGKfw9ph0MyhgSqDWYI5n9W4d6e h//WBWooe/D7ueLZ4QRBlRql9pEPXe5RAR58YRlEjsqLlkNP7SATXIJOU81mV1y9Xn67 NdQX9Spyydfc+Z6b2ppqjjJuyp7NHVfU0UtDjK3sLpHtKOxiOze/LpEUrlemj19au20A XbReJfHN7Awc9CcjCpI0LU65aqoZnB5FjBi24rhyqELyHnsjvCbS1vHaPli91BMo0sbn gL5Q== X-Gm-Message-State: AOJu0YzKucRqMlx8gB9HZwvH8u9Vnf/2630PzEe6BGMb4a0pG89FctVw 0CyECw1XaZLaX+5AGUkU2Ip8thj9cFWKfASKRYfYeTSNp8P+G3RuWaDTUd8m26ybBboiW9pRhNX 9a8vv0oCVclsjVpAmt/9b/18tjFvKKRs3 X-Google-Smtp-Source: AGHT+IHflOLCJ8xWVeWz0CX4oDi6ki5THrHk2a+yU+mbpPOb6yZVhMZefeslkrSA1g82/7bcLCoSNBH97s24oLmYODA= X-Received: by 2002:a05:6512:23a3:b0:539:e513:1f69 with SMTP id 2adb3069b0e04-53b348f97c6mr8060102e87.17.1730351883149; Wed, 30 Oct 2024 22:18:03 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 From: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= Date: Thu, 31 Oct 2024 02:18:11 -0300 Message-ID: Subject: [rtld] fdlopen(), fdlputpath() and capsicum To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12a:from] X-Rspamd-Queue-Id: 4XfC1n4Z1Vz583N X-Spamd-Bar: --- I'm trying to use capsicum to load untrusted plugins (fdlopen after cap_enter), but I've been facing problems as plugins might depend on not yet loaded libraries (LD_LIBRARY_PATH no longer works after we disable ambient authority). 10 years ago rtld gained the option/env-var to specify directory descriptors to be searched instead[1]. However this env-var is only queried at program startup (the use case is not sandboxing plugins through fdlopen(), but whole programs through exec()). exec() is not an option for my use case. Plugins are meant to load functions that extend the current program image (e.g. manipulating data structures or some shared memory). exec() would just kill any use I have for plugins. My project just stalled on this problem this week. A workaround I've been planning was to statically link the plugins to the libraries (they are untrusted, so this step would occur in a jail), but this won't be an option for every plugin (maybe closed source, maybe licensing problems for the library linked with, ...). I'd like to request a new function to use from C programs: int fdlputpath(int fd); fdlputpath() would just modify the private variable ld_library_dirs introduced in the commit which introduced the env var LD_LIBRARY_PATH_FDS. fdlputpath() would have some restrictions similar to putenv[2][3][4]. The change is simple and it'd open the doors to use fdlopen() for capsicum processes. Thoughts? [1] https://git.quacker.org/d/freebsd-nq/commit/02d3b38e0a766bde374de052a2c= 65a095282f302?style=3Dunified&whitespace=3Dignore-all&show-outdated=3D [2] putenv() modifies a global and it's not thread-safe. fdlputpath() would have the same restriction. [3] It's not safe to deallocate old values inserted by previous calls to putenv() as copies/references to old values might be hanging around. fdlputpath() would have the same restriction. [4] Some implementations of putenv() might provoke intentional leaks to avoid the previous problem. Users of fdlputpath() might adopt a similar approach and keep the passed values hanging around as valid resources forever just in case. --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/