[Pkg-shadow-devel] Rationale for O_NOFOLLOW

[FLORENT CHABAUD]

Thanks for the answer.
We have considered the bindfs option but it would first mean to compile the kernel with its support, which raises other issues. 
 
Bien cordialement / Kind regards, 
 
Florent Chabaud  


-----Original Message-----
From: Serge E. Hallyn <serge at hallyn.com> 
Sent: vendredi 28 juin 2024 16:13
To: FLORENT CHABAUD <florent.chabaud at eviden.com>
Cc: pkg-shadow-devel at alioth-lists.debian.net
Subject: Re: [Pkg-shadow-devel] Rationale for O_NOFOLLOW

Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.


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.
>
> 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