Static bins

Christopher James Coleman ug97cjc at cs.bham.ac.uk
Wed Jan 7 11:18:43 PST 2004


On Wed, 7 Jan 2004, Robert Connolly wrote:
> On January 7, 2004 01:26 pm, ken_i_m at elegantinnovations.net wrote:
> > On Wed, Jan 07, 2004 at 01:08:09PM -0500, Robert Connolly
> (cendres at videotron.ca) wrote:
> > > That one setting seems to be the only thing keeping sanity. If there was
> > > a bug
> > > in that setting, a staticly linked /bin/false would prevent further
> > > compromise.
> >
> > I don't use suspenders.  Nor a belt.  I have found through experience and
> > testing that if I wear a pair of pants that fit me they do not fall down.
> > I understand that some folks use both as personal preference.  It does
> > not mean that their pants are more secure against falling down then mine.
> >
> > In other words, I think you are chasing a ghost.  Either sshd is config'd
> > properly or it is not.  The correct solution is to ensure that it is.
>
> Attempting to prevent unknown bugs is why sshd seperates privileges and hides
> in a chroot. Sounds like the sshd developers have concerns about sshd's
> safety. It's not safe just because its configured properly. Any number of
> reasons, including a shared lib attack, could make sshd permit access it
> shouldn't. Staticly linked /bin/false could be the difference between an
> attacker getting a shell, or getting nothing, because of a bug in enviroment
> code; but even still its only a small consideration. But building a few
> programs staticly linked doesn't realy add any overhead, and could add to the
> safety of other applications or daemons. Also, just because these attacks
> haven't been reported in years doesn't mean they can't return tommorrow.

You do realise that there is no reason for /bin/false to be dynamically
linked anyway? All it is supposed to do is exit with a false value. In
fact, it should probably be written in assembly, as all you need to do is
call the exit system call - it does not need the complications of using
the C library.

.chris



More information about the hlfs-dev mailing list