> "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[1] 

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[2] 
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

--------
[1] https://cr.yp.to/talks/2007.04.27/extremesandbox.c
[2] https://matt.ucc.asn.au/dropbear/CHANGES

Reply via email to