${LIB} macro and blacklisting arch-specific dirs

[kmk3]

(Continued from #4871)

@topimiettinen commented on Jan 24:

@topimiettinen commented on Jan 22:

and white/blacklisting could refer to architecture dependent paths.

Well, there are already references to e.g.: /usr/lib64, which may not
exist for all architectures and may not exist on all distros. I think
that this could be helped by adding more macros, such as e.g.:
${LIB}.

Yes, but there could be blacklists blocking some of
/usr/lib/x86_64-linux-gnu/, /usr/lib/i386-linux-gnu/ and
/usr/lib/x32-linux-gnu/ depending on the architecture.

Yes; maybe this could be done automatically when handling
seccomp.block-secondary. Example:

if (arg_seccomp_block_secondary) {
#ifndef __AMD64__
	profile_add("blacklist /usr/lib/x86_64-*");
#endif
#ifndef __ARMV7__
	profile_add("blacklist /usr/lib/armv7-*");
#endif
// ...
}

Good idea, though I'd make it a separate option. This wouldn't help if the
profile files refer to the architecture dependent paths, for example
blacklist /usr/lib/x86_64-linux-gnu/gtk-3.0.

But is it even desirable to have a profile referring to such paths?

A ${LIB} macro could expand to paths like the following:

/lib
/lib64
/usr/lib
/usr/lib/armv7-*
/usr/lib/i386-*
/usr/lib/x86_64-*
/usr/lib64

So given blacklist ${LIB}/gtk-3.0, it would expand to:

/lib/gtk-3.0
/lib64/gtk-3.0
/usr/lib/gtk-3.0
/usr/lib/armv7-*/gtk-3.0
/usr/lib/i386-*/gtk-3.0
/usr/lib/x86_64-*/gtk-3.0
/usr/lib64/gtk-3.0

Note: This would be similar to how private-bin considers a bunch of paths,
including /bin and /usr/bin:

firejail/src/firejail/fs_bin.c

Lines 30 to 40 in 121749f

	static char *paths[] = {
	"/usr/local/bin",
	"/usr/bin",
	"/bin",
	"/usr/games",
	"/usr/local/games",
	"/usr/local/sbin",
	"/usr/sbin",
	"/sbin",
	NULL
	};

Note2: To avoid too many unnecessary paths (especially ones that don't exist on
a given system), maybe the lib dirs that ${LIB} would expand to could be
defined at configure time.

---

With the ${LIB} macro + hardcoded blacklisting, given the following:

noblacklist ${LIB}/gtk-3.0
seccomp.block-secondary

On an amd64 system, this could be the result:

blacklist /usr/lib/armv7-*
blacklist /usr/lib/i386-*
noblacklist /lib/gtk-3.0
noblacklist /lib64/gtk-3.0
noblacklist /usr/lib/gtk-3.0
noblacklist /usr/lib/armv7-*/gtk-3.0  # ignored
noblacklist /usr/lib/i386-*/gtk-3.0   # ignored
noblacklist /usr/lib/x86_64-*/gtk-3.0
noblacklist /usr/lib64/gtk-3.0

The order could be reversed like the above depending on when each command would
be handled, which is not very intuitive. So yeah, I think it's valid to split
running vs accessing non-native code.

Maybe the paths could be managed with something more generic like
${NATIVE_ARCH} (e.g. x86_64) and ${NON_NATIVE_ARCHS} (e.g. i386, arm
etc.), maybe also ${SECONDARY_ARCHS} (i386, x32) for use in paths. So
instead of hardcoding this to Firejail, common profile files could use
blacklist /usr/lib/${NON_NATIVE_ARCHS}-*.

That blacklist command looks like it would work.

And if there are any more paths other than /usr/lib/$arch-*, maybe they could
be put into something like "disable-non-native-libs.inc".

So considering both macros, maybe something like this:

blacklist /usr/lib/${NON_NATIVE_ARCHS}-*
noblacklist ${LIB}/gtk-3.0

But I'm not sure if the paths in /usr/lib would be the same for all distros
(e.g.: /usr/lib/x86_64-* vs /usr/lib/amd64-*), especially considering that
the target "levels" may also be different (e.g.: /usr/lib/i386-* vs
/usr/lib/i486-*). Also, /usr/local/lib may be populated as well.

So maybe something like ${LIB_NON_NATIVE} expanding to the full lib paths?
Example:

blacklist ${LIB_NON_NATIVE}
noblacklist ${LIB}/gtk-3.0

Or maybe create a disable-non-native-libs.inc.in that blacklists all known
paths and comment out the native path at configure time:

blacklist /usr/lib/armv7-*
blacklist /usr/lib/i386-*
#blacklist /usr/lib/x86_64-*

That's as far from hardcoded as I could think of.