I meant a simple (set of) file bind mount(s), which requires no kernel options.
Jun 28, 2024 10:52:38 FLORENT CHABAUD <[email protected]>: > 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
