On Sun, Feb 06, 2022 at 04:59:05PM +0100, Omar Polo wrote:
> Thomas Adam <thomas@xteddy.org> writes:
> 
> > On Sun, Feb 06, 2022 at 12:06:27PM +0100, Omar Polo wrote:
> >> here's a revised diff.  it's equivalent in practice to the previous one,
> >> but hopefully less scary :)
> >
> > Thanks for this.  I have no means of testing this though (the kernel version I
> > have here on Arch Linux doesn't seem to offer Landlock) but I have a few
> > comment in-line below.
> 
> unfortunately it doesn't seem to be that much available yet.  I can
> confirm that fedora has it, and I'm told nixos ship with landlock
> enabled too.
> 
> I just tried on a devuan ceres (unstable) vm and they ship
> linux/landlock.h, but the actual kernel has landlock disabled!  I've
> added a check for ENOSYS and ENOTSUP to handle this situation where
> landlock was found at compile time but it's not present at runtime.

I'd agrue that in the ENOTSUP case it shouldn't fail silently and
should instead return an error, that way distributions attempting
to ship packages have a chance of catching it, rather than shipping
out binaries that don't actually provide any sort of protection.

At least in that case the distros adding --disable-landlock will be
easier spot as well.

If we're going to make comparisons to unveil(2)/pledge(2), it's
at least worth looking at how they handle failure..


    if (pledge("stdio rpath ...", NULL) == -1)
        err(1, "pledge");

-Bryan.