[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