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 <[email protected]> Sent: vendredi 28 juin 2024 16:13 To: FLORENT CHABAUD <[email protected]> Cc: [email protected] 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 _______________________________________________ Pkg-shadow-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel
