Re: Question about using Landlock

--Sig_/eeeeyaCyLpTj=GruAm/cyn1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, 20 Nov 2025 18:36:50 +0100
Micka=C3=ABl Sala=C3=BCn <[email protected]> wrote:

> On Wed, Nov 19, 2025 at 09:19:37PM +0000, Marek K=C3=BCthe wrote:
> > Hello, =20
>=20
> Hi!

Thanks for your answers! That answered many of my questions.

> > When accessing the file system, I'm supposed to specify the fd of the
> > file, but then I already have that file open. And that's exactly what
> > Lockland is supposed to control. =20
>=20
> The goal of a file descriptor is to identify a file or another kernel
> resource, without race condition, and in an absolute way.  It doesn't
> mean it gives access to the underlying resource (but that's the case
> most of the time).  With Landlock, it is encouraged to open files with
> O_PATH (see the sandboxer.c example) to avoid leaking opened
> files/access.
>=20
> Using file paths for kernel interfaces should be avoided.

Could you give an example? I think you mean fd's that don't refer to
anything in the file system?

> Creating files before sandboxing itself can make sense wrt to the threat
> model (i.e. if the potential attacker cannot interact with the process
> at this time).  However, you should try to open the tap device before
> the sandboxing and keep the related file descriptor open.  This way you
> don't need to bother with the file path of the tap device and you avoid
> other potential issues.

Thanks for the clarification. I'm new to developing "secure programs"
and still need to learn how to create (useful) threat models.

> > 3. Lockland introduces scoped access control starting with ABI 6. To
> > avoid getting warnings from the compiler (and linter), I need to know
> > whether the struct landlock_ruleset_attr has scoped access control or
> > not when programming. Since I only want to support the case where this
> > is true, I would like to check the ABI version at compile time and
> > generate a more meaningful error. How can I check the ABI version at
> > compile time? Is there a macro for this? =20
>=20
> Checking the ABI version at build time is not recommended because it
> doesn't give any guarantee about the ABI version at run time.  That's
> why the ABI should be a dynamic check.

But I would like to have a build-time guarantee that certain data
structures are available in a certain form or that certain macros
exist. Hence my question about build-time checking.

> > Currently, I am using a check to see if the compiler can compile the
> > struct with `scoped`. [5] However, I don't think this is very elegant. =
=20
>=20
> If the scoped field is defined, then you should use it and update it at
> runtime according to the current Landlock ABI.  See the sandboxer.c
> example for such case.

But that assumes that the field exists at build time, and that's
exactly what I want to check.

If I try to initialize a non-existent field, there should be an error
from the compiler (so I want to catch that beforehand). And if I don't
initialize an existing field, clang-tidy complains.

As far as I can tell, sandboxer.c always assumes at build time that it
has been compiled with a new version. Or am I overlooking something?

--=20
Marek K=C3=BCthe
[email protected]
er/ihm he/him

--Sig_/eeeeyaCyLpTj=GruAm/cyn1
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmqKBWfzrPNg7whIBfoaRRmmRCMcFAmkffBkACgkQfoaRRmmR
CMdTtw//Rx76J7rhN29Mp8ptokaoe+yTAIEX3Gs9EDkUtyQPTNxD0ATonj+H3wmp
DF2aCZW+RVP5hqgILDuvVHcIpAPMbOk1EqGyH7uZDKgiU31Dq7ECthhZT2KMCXJf
g/tUuyZ9UUe5Ep/iVe5zqLOCVARQk5vZ/fFiOflS9fjc2xv089b9lxyMnexK6+A+
eV5LwWd5293VKx6ITeSArX/ziAO/wAwUm2ZkwZyGDSIMAQ0xbsa/DZSy30OCCTAf
Le8WpL0sBR2CQxxm2WqYPXdI4vNAjEeNm1l2stLqKmlxj12m7j6tj0YKTBZxRjv7
GUQkhKA23qCI7erLipMREx7Vw6ffVVtDpfebn2+2KWfhHXNoSxZ+0M2Zs74C6qSU
RBcY1nwnaLJa+Lg1dtb0Jg2wcq03mHPuX59Jyfln6LYURXnvcmXJBk3R7ddw+dK3
h7tqSajK5Y8Wx7w2M2+zeKB2qtxtZECcvjANyVgKGJ4UJKTSPtx2Uz6LZWCeIfs1
ympgCCWuiOOSH4/qQ3j/HDaCKAhmNUXsI5T8iGQHG7fGMDuc6hK9OjTQJyp6sH0s
gxcsRQtsrm1ItvNW6O5puXu3RAGpGQWRRhcfuvJA3BkzPg+P+KgwM5JO5T3SIsFT
l0U48J5QEC3iIjxlLstrljZ4cEqVMMwTGIrZjaDSiT2ZjhGOmac=
=Rw+h
-----END PGP SIGNATURE-----

--Sig_/eeeeyaCyLpTj=GruAm/cyn1--