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>