Static bins

Robert Connolly cendres at videotron.ca
Wed Jan 7 09:18:42 PST 2004


On January 7, 2004 12:05 pm, Bennett Todd wrote:
> 2004-01-07T11:20:22 Robert Connolly:
> > What do you guys think about building some bins
> > static. Specificly ping, su, passwd, /bin/false. Is there any
> > reasons these are more secure dynamicly linked?
>
> I think there are two security issues in the neighborhood of static
> -vs- dynamic linking.
>
> Historically, there have been some glitches with handling things
> like LD_LIBRARY_PATH and LD_PRELOAD, in the face of suid
> executables. Those have as far as I know all been fixed, long ago,
> but even so if someone can control the envars in which a
> differently-privileged process runs a dynamically linked executable
> they can exploit these. So good practice requires that you prevent
> users from being able to influence LD_* envars across privilege
> boundaries. Not a big deal, not at all.
>
> If a library itself has a bug, deploying the fixed version of the
> shared lib fixes all dynamically-linked executables as starting with
> their next invocation (i.e. persistent daemons may need restarting);
> with static linking, you have to rebuild and reinstall everything
> that depends on the lib. Strong software packaging can help bring
> this cost down, but it's still there.
>
> I think other, non-security-specific issues are stronger drivers in
> the dynamic -vs- static linking debate.

If a system is running ftpd and sshd, where a user has ftpd access but not 
sshd shell, and has a shell of /bin/false, I think the only thing preventing 
the user from forcing a shell is a single setting in the sshd_config 
disallowing enviroment vars. If thats still true, then it would certainly 
help if /bin/false were staticly linked; and why stop there when suid bins 
share the same theroretical problem.





More information about the hlfs-dev mailing list