[uClibc] status of uClibc shared libraries and ARM?

Bennett Todd bet at rahul.net
Wed May 5 12:56:04 UTC 2004


2004-05-05T12:28:06 Chris Wilson:
> > Sounds like it's not subject to the security problem glibc's ld has,
> > where someone could bypass noexec mounts by using ld-linux.so
> > explicitly to load the executable.
> 
> This is no solution, since it's always possible to compile your own ld,
> which supports loading in this way, upload it to the machine and run it...  
> there must be countless ways to run programs from a noexec partition.

Of course, if you have a full dev env you can bypass a great many
controls.

If, however, you're on an appliance (or a shared system) where the
only space you can write is mounted noexec, you do have a
bootstrapping problem, how to get your rebuilt loader executable in
the first place.

It's certainly impractical, today, to perfectly harden a system
against local users (although sandboxing and priv-limitation setups
like RSBAC and selinux are improving matters here).

But inability to achieve perfection doesn't mean you should never
try to make things better.

uClibc dodged a bullet that glibc took, that was all I wanted to
point out.

I like uClibc.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20040505/82e6683c/attachment-0002.pgp 


More information about the uClibc mailing list