|
> "extremely outdated"? > > This sounds like a hack from ~ 20 years ago when people realized that > running several programs at the same time as nobody does not isolate > them from each other. > > Much better solutions for restricting what a process can or cannot do > are now available. >
The basic idea is taken from extreme - sandboxing: https://cr.yp.to/talks/2007.04.27/extremesandbox.c
My 2 tools currently making only small part on this idea, only droping uids/gids. I would like to improve my tools in the future,
but I thing first step: - running current daemons/cron scripts/... under differentd UIDs in the system simply by using extremesetuidgid/extremeenvuidgid (instead of setuidgid/envuidgid)
second step: - create (library ??) to use buggy libraries such openssl sandboxed using idea from extreme sandbox
> tinysshd [1] is another worrisome example. > > Writing an own "tiny" sshd from scratch, and the result is not even > smaller than the dropbear everyone else uses for that purpose.
dropbear is nice example here. https://matt.ucc.asn.au/dropbear/CHANGES First line in the changelog: """ Security: Message printout was vulnerable to format string injection. """
I'm trying in my software eliminate bugs such 'format string injection', this is exactly why I'm not using sprint*,vsprint*,... and other functions from libc, and also trying to eliminate varargs functions.
> > To make the NIH complete, it uses own versions of standard C library > string functions and an own (pretty primitive) build system.
Yes, the build script (and also Makefile) is very small. I'm following the rule "less code means less bugs" Everyone can read what it does. It simply works on Linux, *BSD, Solaris, AIX, ...
Jan |