From nobody Thu Oct 31 06:08:16 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 4XfD802lRwz5bBqg for ; Thu, 31 Oct 2024 06:08:32 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4XfD7z2qQfz40VV for ; Thu, 31 Oct 2024 06:08:31 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kib@freebsd.org) smtp.mailfrom=kib@freebsd.org; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none) Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 49V68Gmf088094; Thu, 31 Oct 2024 08:08:19 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 49V68Gmf088094 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 49V68GSV088093; Thu, 31 Oct 2024 08:08:16 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Thu, 31 Oct 2024 08:08:16 +0200 From: Konstantin Belousov To: =?utf-8?B?Vmluw61jaXVz?= dos Santos Oliveira Cc: freebsd-hackers@freebsd.org Subject: Re: [rtld] fdlopen(), fdlputpath() and capsicum Message-ID: References: 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; RCPT_COUNT_TWO(0.00)[2]; TAGGED_RCPT(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[kib]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MISSING_XM_UA(0.00)[] X-Rspamd-Queue-Id: 4XfD7z2qQfz40VV X-Spamd-Bar: -- On Thu, Oct 31, 2024 at 02:18:11AM -0300, Vinícius dos Santos Oliveira wrote: > 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/02d3b38e0a766bde374de052a2c65a095282f302?style=unified&whitespace=ignore-all&show-outdated= > [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. Try this https://reviews.freebsd.org/D47351