On Thu, Sep 23, 2021 at 08:42:21AM +0200, Omar Polo wrote:
> Hello,

Hi,

>   1.  landlock persist across execve(2)
> 
>       This is a major pain because, even if stsp@ told me that unveil
>       usage in got already takes this assumption into account, ld.so (or
>       whom it may concern) in the executed binary can't open the shared
>       libraries.  I'm addressing this with a allowing "rx" on "/lib64",
>       but this works only on the linux machine I'm using, I don't know
>       if it's possible *at runtime* too obtain the path of the linked
>       libraries and add that, or do some other kinds of "magic" in this
>       regard.
> 
>       This is a (the only?) major problem that I still have to sort out.

Could rpath help out here?

> How I'm trying to adding it in -portable
> ========================================
> 
> Only inside the got/ directory there are 95 matches for "unveil" and
> even if some of them are the "unveil" pledge promise I can't
> realistically change every call to unveil into, say,
> got_landlock_something_something.
> 
> At the moment, unveil in -portable is handled by a macro in got_compat.h
> 
> 	#define unveil(s, p) 0
> 
> My idea is to provide an unveil-like API in compat/unveil.c based on
> landlock.  Doing so allowed to add landlock support by breaking least
> code possible.
> 
> The result is pretty good IMHO, and it's possible to reuse unveil.c on
> other projects too.

I think I'd prefer to see something like this, albeit I suspect we will need
to:

1.  Remove the #define unveil(s, p) 0 and allow calls to unveil() be a trigger
for calling landlock_*() functions.

2.  Provide host-checking so that if we have a landlock-enabled system, we can
do something like this in compat/Makefile.am:

    libopenbsd_compat_a_SOURCES += compat/osdep-@PLATFORM@.c

I have the detection for this on the 'freebsd' branch in got-portable.git if
you wanted to take a look there.  It currently compiles fine under both
FreeBSD and Linux.

I'll look at the test suite later on.

Kindly,
Thomas