Rethink /usr/local/lib* → /usr/lib file path aliases?

[ipilcher]

I recently hit a situation in which a file context rule was failing to work for a path under /usr/local/lib64/. Sure enough, it turned out to be yet another alias problem.

config/file_contexts.subs_dist contains the following aliases:

/usr/local/lib32 /usr/lib
/usr/local/lib64 /usr/lib
/usr/local/lib /usr/lib

These were added back in 2012, but the commit message doesn't provide any reasoning for them.

Personally, these aliases seem pretty odd. The /usr hierarchy is generally intended for things that are managed by the distribution, where /usr/local is for stuff that is managed by the local administrator, so the two are very much not the same thing (unlike /run and /var/run which are both distribution-managed).

Can/should the presence of these aliases be rethought?

[pebenito]

In my mind, the common case for /usr/local/lib(32|64)? is for it to work the same as /usr/lib. If it doesn't do so, then it will be very surprising.

[jjess8360-collab]

[!IMPORTANT] #@+

[WavyEbuilder]

The /usr hierarchy is generally intended for things that are managed by the distribution, where /usr/local is for stuff that is managed by the local administrator, so the two are very much not the same thing (unlike /run and /var/run which are both distribution-managed).

I mean I guess, but I don't really see any practical security benefits to be gained by creating new _local_ts or something akin to that. Distros that want to enforce integrity on /usr hierarchy are much better suited to another tool, such as fs-verity or dm-verity and having /usr be a separate partition, with a symbolic link from /var/usr_local to /usr/local.

However, there are a few notable downsides, namely a load of existing macros and interfaces would have to be updated, and there's e.g. lib_t vs lib_local_t. What would the difference be? I don't really see the use case here, but maybe I'm missing something?

I recently hit a situation in which a file context rule was failing to work for a path under /usr/local/lib64/. Sure enough, it turned out to be yet another alias problem.

Could you maybe expand on that? Personally not sure how having new types would help, unless you're suggesting something else.

[ipilcher]

The /usr hierarchy is generally intended for things that are managed by the distribution, where /usr/local is for stuff that is managed by the local administrator, so the two are very much not the same thing (unlike /run and /var/run which are both distribution-managed).

I mean I guess, but I don't really see any practical security benefits to be gained by creating new _local_ts or something akin to that. Distros that want to enforce integrity on /usr hierarchy are much better suited to another tool, such as fs-verity or dm-verity and having /usr be a separate partition, with a symbolic link from /var/usr_local to /usr/local.

My point wasn't that a new type should be created. My point was to get rid of the (IMO) confusing aliases:

/var/named/chroot/usr/lib64 = /usr/lib
/var/named/chroot/lib64 = /usr/lib

These aliases mean that a file context rule like this will not work.

/usr/local/lib64/fdf-filters(/.*)?      system_u:object_r:fdf_lib_t:s0

Instead, the rule has to be written like this.

/usr/lib/fdf-filters(/.*)?              system_u:object_r:fdf_lib_t:s0

This is true even though there's no thought/intention of it ever actually applying to files under /usr/lib. It's incredibly counterintuitive.

[0xC0ncord]

I see your point, but I'm not sure how best to approach this, or even if we should do anything about it at all.

Realistically we could remove the aliases and just blanket /usr/local/lib as lib_t, but this could potentially break systems relying on the alias behavior.

[WavyEbuilder]

This is true even though there's no thought/intention of it ever actually applying to files under /usr/lib. It's incredibly counterintuitive.

I can see that as a bit counter-intuitive. Maybe we could sell userspace on parsing filecon statements to resolve there too? Not sure how much work that would be, nor what the implications could mean: is there any reason to rely on this behaviour?

However, as @0xC0ncord says, I don't think there is anything we can or should do in the refpolicy repo, the risk of breakage for both existing filecon statements are enormous and I can almost guarantee there are filecon statements in the repo right now that depend on the subs_dist.

[pebenito]

I can see that as a bit counter-intuitive. Maybe we could sell userspace on parsing filecon statements to resolve there too?

IMO, this would be the best choice.

However, as @0xC0ncord says, I don't think there is anything we can or should do in the refpolicy repo, the risk of breakage for both existing filecon statements are enormous and I can almost guarantee there are filecon statements in the repo right now that depend on the subs_dist.

I also agree with this too.

[WavyEbuilder]

IMO, this would be the best choice.

I'll start working on a patch for that