[Pkg-shadow-devel] Rationale for O_NOFOLLOW

[Serge E. Hallyn]

On Wed, Jun 26, 2024 at 12:59:26PM +0000, FLORENT CHABAUD via Pkg-shadow-devel wrote:
> Hi everyone,
> 
> As this is my first message on the list, let me introduce myself. I'm in charge of Product Security at Eviden, and I'm currently interested in hardening some Baseboard Management Controller (BMC) running on linux (OpenBMC). As a company, we are an HPC and Enterprise server vendor.
> 
> As part of this hardening effort, we are investigating some mechanisms to segregate some critical files in a separate memory area, for instance /etc/passwd and /etc/shadow. The rationale for this is that these files may have to survive some reset-to-defaults, while being kept read-write in normal use. The user may want to change its passwords 😉. On the other hand, other files in /etc must reside in read-only memory as they are bound to the hardware.
> 
> The approach we had in mind was to move the corresponding files in a different location and set a symbolic link at the usual place in /etc. During testing, we discovered shadow limitation which prevents from following links. Namely, the opening of file in lib/commonio.c uses O_NOFOLLOW flag.
> https://serverfault.com/questions/491033/cannot-useradd-adduser-when-etc-passwd-shadow-group-are-symlink-debian-squee
> 
> As we are in some embedded linux, we could just recompile shadow without this flag. But before doing this, I'd like to understand the rationale for this flag. Can anyone provide clarification on this?
> 
> Thanks in advance.

It's not explicitly documented in git history, but presumably only the
obvious reason - a symlink there could be suspicious.

I'm not convinced that patching out the O_NOFOLLOW would be easy to
exploit, but I'm also not imaginative enough to trust that I've
thought of all the possible issues.

Have you considered using bind mounts instead of a symlink?

-serge