Re: Capsicum and weak libc symbols

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
>