Date: Mon, 04 Nov 2002 11:32:38 -0800 From: Tim Kientzle <kientzle@acm.org> To: Miguel Mendez <flynn@energyhq.homeip.net> Cc: morganw@chemikals.org, current@FreeBSD.ORG Subject: Re: libc size Message-ID: <3DC6CB56.8090809@acm.org> References: <3DC17C7F.9020308@acm.org> <20021031140542.W86715-100000@volatile.chemikals.org> <20021031220633.3acd0b53.flynn@energyhq.homeip.net> <3DC1AB26.5020708@acm.org> <20021103155858.3be6eda9.flynn@energyhq.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Miguel Mendez wrote:
> Tim Kientzle <kientzle@acm.org> wrote:
>>1) Fragility. Could a naive sysadmin (or a dying
>> disk) break /[s]bin?
>> What if the ldconfig hints files were hosed?
>> Is ld-elf.so truly bulletproof?
>
> Agreed, and, fortunately, that was taken into account with the
> introduction of the /rescue dir:
>
> christine: {48} du -h /rescue
> 2.4M /rescue
Oh. So the real size of NetBSD's /bin and /sbin includes
another 2.4M for /rescue. That makes it less
impressive. I don't find the duplication appealing, either.
(Why not just put the /rescue versions directly
into /bin and /sbin? That would be smaller still,
wouldn't it?)
>>2) Security. Can LD_LIBRARY_PATH (or other mechanisms)
>> be used to deliberately subvert any of these programs?
>> (especially the handful of suid/sgid programs here)
Several people have pointed out that FreeBSD has
certain protections against LD_LIBRARY_PATH exploits,
but there are still real questions here. (Kernel
races, possibly?) Privilege elevation is an
interesting idea, but tricky to audit.
>>the results from ls -l /bin on your NetBSD system
> christine: {66} ls -l /bin
> -r-xr-xr-x 1 root wheel 8480 Oct 29 22:59 cat
> -r-xr-xr-x 1 root wheel 4892 Oct 29 23:00 echo
> -r-xr-xr-x 1 root wheel 5568 Oct 29 23:01 rmdir
> -r-xr-xr-x 1 root wheel 5892 Oct 29 23:02 sleep
> -r-xr-xr-x 1 root wheel 4652 Oct 29 23:02 sync
> [[ others omitted ]]
<sigh> I've been looking at some of the FreeBSD standard utils,
and with a very little bit of work got this:
-rwxr-xr-x 1 tim tim 9552 Nov 4 11:10 cat
-rwxr-xr-x 1 tim tim 2776 Nov 4 11:10 echo
-rwxr-xr-x 1 tim tim 3288 Nov 1 13:48 rmdir
-rwxr-xr-x 1 tim tim 2904 Nov 4 11:10 sleep
-rwxr-xr-x 1 tim tim 2424 Nov 4 11:10 sync
All statically linked, all portable C, with identical
functionality to the originals. If statically-linked
versions can be 1/2 the size of the dynamic versions,
then I _really_ don't see the advantage of dynamic linking.
Perhaps some more careful programming is all that's needed? ;-)
(Admittedly, a space-conscious overhaul of sh, csh, or ed
is not entirely trivial; but most of /bin and /sbin is pretty simple
to prune down.)
> rcNG has been in work for a long time. Is it worth it? Absolutely,
> try it once and you'll wonder how you could live with the old system, or
> even with the sysV symlink crazyness.
As it happens, I've been looking closely at RCng
just recently. Though I really like the core design, I do
have some quibbles with the implementation. It
is usable today, and does address the worst problems
of SysV-style init. Still needs some work, though. ;-)
Tim Kientzle
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC6CB56.8090809>