Page 1 of 1

[not4n00bs] A "secure" libc...

Posted: 14 Nov 2017, 23:37
by n0ctilucient
It's no secret I favor Musl over glibc (GNU/Linux) because like Google's
Bionic (software) it is immune to browser exploits like Return-to-libc attack .
One Linux-based package that's not vulnerable is Google's Android mobile
operating system. It uses a glibc substitute known as Bionic and isn't susceptible...

see... https://arstechnica.com/information-tec ... ulnerable/
also... https://security.googleblog.com/2016/02 ... k.html?m=1
You can find Musl @... http://slakfinder.org/index.php?act=sea ... e=#results
Source is @... https://www.musl-libc.org/releases/

In any case... although I addressed this issue in an earlier, thread (as "fullmoonremix")
I have since found, another way to enable musl libc as a glibc drop-in.

Renaming /usr/lib64/musl/ld-musl-x86_64.so.1 to ldd and copying it to
/user/bin to overwrite the original ldd is the initial way to deprecate glibc.

However... ld-musl-x86_64.so.1 is actually a symlink to /usr/lib64/musl/libc.so.1

That means you can send /usr/lib64/musl/libc.so.1 to a /root/Desktop symlink
and rename it "ldd" and then copy it to /usr/bin to overwrite the original ldd.

I use this tactic with my Porteus default menu by creating 2 modules
named 04-default.xzm (Musl) and 09-default.xzm (w/ the "new" ldd).

You can actually use 1 module but I like to keep modifications separate.

Then in porteus.cfg... I rename the 1st menu entry "Userland" and the 2nd entry "Toolchain".
Then I use the identical cheatcodes only changing the 2nd entry to include... noload=default.

@ boot when I want to develope... I select "Toolchain" (glibc :wall: )
and for everything else (that plays nice w/ Musl ) "Userland".

B) I made this thread while booted into (and protected by)
Musl which also runs in my Kasda ( OpenWrt ) wifi router.

Please Note: One should (if possible) make remastered module
changes in /root/Desktop to avoid breaking module symlinks.

It's been a while since I've reached out to src2pkg's creator but since
musl libc breaks src2pkg's "setup" perhaps he knows a workaround.

Or maybe the solution lies in /usr/bin/musl-gcc?

Or perhaps... Embedded GLIBC .
Source is @... https://downloads.yoctoproject.org/releases/eglibc/
Debian package is @... http://www.emdebian.org/debian/pool/main/e/eglibc/

More to come...

[not4n00bs] ...A Better "libc"

Posted: 19 Nov 2017, 16:53
by n0ctilucient
Ok... reached out to Gilbert (src2pkg).
The following is his solution...
export CC /usr/bin/musl-gcc ; src2pkg --setup

[not4n00bs] ...A Better "libc"

Posted: 30 Nov 2017, 01:31
by n0ctilucient
Updated my post.. An alternate script is to follow.

I also need to ask if this solution can be
added to /etc/src2pkg/src2pkg.conf... :%)
see... Src2pkg.conf w/ "hardened" EXTRA_FLAGS

If everything works out... there is a pathway to
a "hardened" Musl build of ALL binaries...

Hardened Gentoo and Alpine Linux use this strategy.

[not4n00bs] ...A Better "libc"

Posted: 26 Jan 2018, 16:44
by n0ctilucient
Update... very busy doing a rebuild.
But I do intend to reach out to Gilbert again.

Unfortunately... the situation
is... Musl still breaks src2pkg.

I am considering... Embedded GLIBC
as a possible workaround.

[not4n00bs] ...A Better "libc"

Posted: 16 Feb 2018, 11:53
by n0ctilucient
I can boot my system with Musl :celebrate3: but I CANNOT compile on it with src2pkg :wall: (@ least in my initial testing).

More to follow...

[not4n00bs] ...A Better "libc"

Posted: 16 Feb 2018, 12:22
by n0ctilucient
Update... trying to get Musl to play nice with Tiny C Compiler .

[not4n00bs] ...A "secure" libc...

Posted: 19 Feb 2018, 23:21
by n0ctilucient
Update... expanded original post. Added additional instructions.

[not4n00bs] A "secure" libc...

Posted: 18 Mar 2018, 16:57
by n0ctilucient
Update...

I found a workaround... :celebrate14:

To use Musl w/ src2pkg setup ("helpers") simply...

1) ...Boot w/ Musl
2) ...Install Glibc
3) ...After running "helpers" replace "ldd" w/ the original Musl "ldd" (...the link to /usr/lib/libc.so)