From nobody Fri Feb 07 16:56:33 2025 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 4YqKr24tRbz5mThR for ; Fri, 07 Feb 2025 16:56:34 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YqKr24HrPz3wp1; Fri, 07 Feb 2025 16:56:34 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1738947394; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=R1DVY43g9PXaV+0gUryOgJ8FzT9DGxJz2K5rYKEjCkA=; b=rAhhjxKt2jy5KdO7eIHQtJVEYzOh9QqrohNJZ1hJYD29M6fuFeM3HJIsAjZCg5Ps+SmJDu fKpsS2/GvqgE1kbgPQjtuaMPe69W3uyGxIuPJyhzPHEaXvtg//KpBXF5JjAo8jji3bkOaZ EGAk18+e7hcwF4YpPEjbPBeDlds3yIrWSYS415mti4j2DGt/fGU8qfcoE6nIRSzme14SRr wHLAgVb4RpOErrzvXELbhPJN4TFM0HXBRCJ88BM9yago+UxPinV4PEgWy8aa696YFWZMgP wf3LCpPybT+rlhxCLHkj0fN7PVftdtFkxvZ/EgoJYY64VLXKqPnxdbgtcZrfGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1738947394; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=R1DVY43g9PXaV+0gUryOgJ8FzT9DGxJz2K5rYKEjCkA=; b=l/waqllYD81bmlAuieZcp0bm+fBbUA/sx+ByDqyyZVXzAfB8yz8wlk5MTY8qbPM/0n+Svs StwoJuoh2It+GnbPoWmqa4bja2zYhreBQT5KvDXT0qh25k9D1MNWqCIIKx+LI6vS7+yekZ Yw3veGIckBdY5qNqKgn6qKTsZj1zZ0oqtvbDghFQhD92PD1yjCv7mkIYcSMf+eeBXA+Rpo Xk6WQq1RCB7heRz+poQQDfIgeXiTp1y8Ugi4OLOklFrb9aNdStKn7r7jhxqv5cRck/ziJu H5+7y7HesDuqpdC7Pc562Yu8URnPjBdczRJo5KdcPcxfTiBTKC28mRlF4E4XVw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1738947394; a=rsa-sha256; cv=none; b=xeApMHcYOIIpbNG0JZuRpXXiJJj5aBZOUFEGXu9TiYfDttKUSdyHb1+Ae80POxKmVg2Btj wYfZkyc/7eow5utvJeGrpe1tKeQ4cPu1h6iev5RpkZDJlqIQW8y9xSDQBE8yhhhYqg7iWT KW084GXJ2DdlqqAVUD51WnAQuLiNLLCHDauGSwbBphOZ9kMIbPIGQ5cQYnK2QCP1nx0Va1 Ums0Qk6y+p1psuHrp6TQFtPne2CDKPhlqx+9anKF/1n4UihHH1qdpxmaCu0N2Dnxe5puyo wnOPTuu6IkXPKM6QBSxAo34CE016vkogDQCJDGjkHQE4EqQIk//9sIS/g+h3NA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4YqKr23Nrvz1C2k; Fri, 07 Feb 2025 16:56:34 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id D5BD43C01A0; Fri, 07 Feb 2025 16:56:33 +0000 (UTC) Date: Fri, 7 Feb 2025 16:56:33 +0000 From: Brooks Davis To: Vin??cius dos Santos Oliveira Cc: freebsd-hackers@freebsd.org Subject: Re: Capsicum and weak libc symbols 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=us-ascii Content-Disposition: inline In-Reply-To: To clarify, what do you mean by "static" in the first paragraph? In general I think we could make those symbols weak and expose __foo() where it makes sense (the __sys_ namespace is reserved for actual implementations of system calls.) That being said, I don't see a lot of value in most of the __foo() versions. Maybe __getaddrinfo(), but the rest are trivial wrappers around something else. The __foo() versions are almost certainly going to live in the implementation namespace . As to policy, I don't think there is on. It looks like stat() and lstat() stopped being weak mostly by accident when they were converted to use __sys_fstatat in the ino64 converstion. The others have never been weak. That being said, attemping to filter arguments like this is subject to time of check vs time of use vulnerabilities so you need to be quite clear what your threat model is. If you aren't familiar with it, Robert Watson's paper "Exploiting Concurrency Vulnerabilities in System Call Wrappers" is required reading. http://www.watson.org/~robert/2007woot/2007usenixwoot-exploitingconcurrency.pdf -- Brooks On Thu, Feb 06, 2025 at 10:40:52PM -0300, Vin??cius dos Santos Oliveira wrote: > Static builds for libc have many symbols declared as weak so other > projects can override them not only in dynamic builds by just defining > the same name. In a project of mine, I need more functions from libc > to be declared this way. > > For context, Capsicum disables access to ambient authority and forces > users to come up with capability-aware versions of old functions. > Libcasper is a library found in FreeBSD that offers capability-aware > versions of the most used functions in Capsicum sandboxes (e.g. > cap_getaddrinfo). However libcasper doesn't override functions from > libc and one has to rewrite old code just to inject an extra parameter > (cap_channel_t) that in the end could just act as a global variable > anyway. > > Some projects such as Val Packett's Capsicumizer[1][2] interpose > functions from libc so old code can keep working in Capsicum > sandboxes. It's not really very useful to use Capsicum + libc > interposition to virtualize access to OS resources. If the intention > is just to run something akin to containers, one is better off using > jails. However it's still useful to interpose certain functions from > libc to make strategic use of existing libraries. > > I developed an easy-to-use Lua library that allows one to implement > policies for libc functions that are interposed by my project[3][4]. I > intend to use this library to implement IM clients (e.g. Telegram[6], > nostr) that run media parsers and user-downloaded extensions within > sandboxes. Eventually I want to run even torrent clients making use of > Capsicum sandboxes, but I'm still far from this milestone. While I was > exploring this approach, I missed weak attributes for the following > functions from libc that I'd like to interpose: > > * remove() > * stat() > * lstat() > * opendir() > * getaddrinfo() > > I'll also need symbol aliases (e.g. __sys_getaddrinfo) that point to > the original definition of these functions so I can refer to them from > my interposers. What is the process within FreeBSD to decide which > libc functions are targets for interposition (hence will have an alias > + weak attribute on static builds)? I'd like to request a change in > libc so the above functions are defined as weak in static builds + > aliases become available. I've been interposing these functions in > Linux already with little to no problem[7][8]. I'm also trying to > unify sandbox creation for Linux/FreeBSD so Linux developers can > create sandboxing-employing apps that work on FreeBSD with no changes. > > [1] https://github.com/valpackett/capsicumizer > [2] https://val.packett.cool/blog/use-openat/ > [3] https://gitlab.com/emilua/emilua/-/blob/dc2b50e1f68d1c1e1696a5d150f23a7b88cc8efd/test/libc_service_getaddrinfo.lua > [4] https://gitlab.com/emilua/emilua/-/blob/dc2b50e1f68d1c1e1696a5d150f23a7b88cc8efd/test/libc_service_cat.lua > [5] https://gitlab.com/emilua/emilua/-/blob/v0.11.0/src/freebsd/libc_service.cpp > [6] https://github.com/tdlib/td > [7] https://gitlab.com/emilua/emilua/-/blob/v0.11.0/src/linux/glibc/libc_service.cpp > [8] https://gitlab.com/emilua/emilua/-/blob/emilua-0.11.x/test/libc_service_lstat1.lua > > -- > Vin??cius dos Santos Oliveira >